結構之間的關系是伴隨著時間的推移逐漸形成的，因為我們把不同的部分看成整體的一部分在實踐中，我們應該盡量避免這樣做

最近幾個月有很多工作要做我過得很艱難，需要休息我的放松方式是讀書，我選了劉的《三體》在我開始閱讀之前，我從來不知道這本書，也不知道三體，但讀完之后我感到震驚《三體》是一部科幻小說，是地球過去三部曲的第一部這本書構建了一個三體——經典力學中最復雜的問題之一，并圍繞它講述了一個故事所以讓我在不破壞原著的情況下，用自己的方式做同樣的事情

三體問題

為了解釋三體及其與軟件開發的關系，讓我從單體問題開始單體問題更常被稱為有心問題向心力問題試圖確定一個質點在一個中心力作用下的運動狀態，這個向心力源的位置是固定的說白了，恒星可以看作是靜止的行星的運動可以用三角函數來表示

考慮一個稍微復雜一點的情況我們假設兩個質量體通過引力影響對方的運動狀態，也就是兩體問題這可以用來描述地球和月球相互繞轉的運動或者舉個更好的例子，冥王星和冥衛一，如下圖動畫描述

冥王星—卡戎系統的側視圖顯示冥王星圍繞它外面的一點旋轉。

對于包括重力在內的多種力，廣義二體問題都可以轉化為二體問題，這樣二體問題就可以完全解決了所以兩體問題也有相應的解決方法

但是如果我們再增加一個質量物體，把整個系統變成一個三體，那么事情就會變得不可預測，經常會陷入混亂對于大多數初始條件，三體沒有像單體或雙體問題那樣的一般封閉解

軟件開發中n體問題的建立

三體和軟件開發有什么關系其實無所謂但如果我們思考這兩件事，可以發現它們是相似的相互影響的強耦合函數和弱耦合函數可以在同一個系統中和平共存，而不強迫其中一個發生變化我們來對比一下軟件開發和N體問題

起初，事情很簡單，容易理解我們有一個主角，也就是一個中心，其他一切都圍繞著這個中心旋轉軟件里功能不多，不會互相沖突

例如，我們計劃開發一個庫存管理應用程序我們需要做的只是插入新條目，添加或刪除數量，并了解庫存狀態所以我們完成了這些功能

過一段時間，我們需要添加一些新的東西最好開個網店在網上賣產品所以我們開始給庫存管理軟件增加新的功能

首先，添加一個網頁我們用可用量獲得庫存狀態現在這個網頁需要描述可用庫存的狀態，但這并不意味著這些原本可用的商品不在庫存中，它們只是改變了狀態所以我們需要在庫存中設置一個新的狀態我們需要知道處于現貨狀態的貨物數量和處于可銷售狀態的貨物數量

但是現在我們需要改變獲取網店可用數量的操作來反映這種變化如果我們賣不出去，倉庫里有多少貨也沒用我們只想顯示在線商店中的現貨數量我們需要再次修改網店

系統中某些物體的引力吸引其他物體改變其運動狀態這兩部分之間存在競爭，直到達到穩定狀態一旦我們優化了函數，事情就會回到原來的可預測狀態一切都按計劃進行，這使我們很高興我們仍然可以相對容易地預測接下來會發生什么，并知道一個部分的變化會如何影響其他部分

兩個質量相差很小的物體圍繞一個共同的質心運動。

但是事情可以優化我們可以為顧客提供快遞服務因此，我們檢查了現有的系統，并在每一步都進行了更改

快遞服務擴大了商業貿易一個倉庫已經不能滿足需求，我們希望在更多的地方發展業務，系統需要能夠支持這種工作方式但是這將如何影響現有的系統呢需要調整庫存以適應多個位置由于該網站將減少庫存商品的數量，它也需要修改，以支持多個位置但是如何做到這一點呢這也需要庫存和快遞服務的變化...真是一團糟

三個初速度為零的相同物體在等邊三角形頂點的近似軌跡回到單體問題。

怎么才能避免這個問題呢如何才能防止一個功能對其他功能產生嚴重影響

太陽系中有很多質量足夠大的行星，可以影響彼此的運動狀態可是，如果我們試圖預測地球圍繞太陽的軌道，我們可以完全忽略所有的行星，只關注太陽和地球這將給我們一個足夠好的實際運動的初始近似對木星軌道和任何其他行星軌道的預測也是如此

如果我們將軟件系統的兩個功能解耦，就可以像處理太陽系中的行星一樣處理它們一顆行星的引力不足以影響另一顆行星的軌道雖然確實它們仍然相互影響，但是這些影響帶來的變化不會很明顯，在某些情況下甚至不存在

想象一下，如果我們試圖計算未來十年復活節的日期復活節是基督教的節日，在春分后第一個月滿月后的第一個星期天當我們計算這些日期時，我們真的關心木星的79顆衛星嗎當然，我們也不必那樣做

我們把軟件開發方案分解成許多小部分，讓每個部分圍繞太陽運行這里的孫可以是一個信息中介，一個服務總線，或者僅僅是一個已建立的契約決定我們的太陽系需要多少解耦繞著太陽轉的小部件是模塊，域還是微服務并不重要重要的是小部件應該盡可能的獨立這將使他們更容易理解你甚至不需要知道木星有79個衛星來這樣計算復活節日期

事實上，月球顯著地影響著地球的軌道如果我們關心的是太陽和地球的關系，那么我們不是在說地球和月亮繞太陽的軌道，我們只是在說地球的軌道無論一個函數有多復雜，我們只需要在整個系統中把它們看成一個整體

這樣，我們不需要處理太陽系120萬個天體，也不需要處理大約700個行星，小行星或衛星我們只考慮八大行星因為一般來說，當我們談論太陽系的時候，我們只關心這八顆行星雖然這個計算結果并不完美，但對我們來說已經足夠精確，不會給我們的工作帶來問題

簡化問題

當我們考慮倉庫的庫存時，我們到底在考慮什么可能是一個大倉庫，里面儲存了很多貨物倉儲工作是什么為了儲存貨物直到出售我們的軟件系統應該只考慮這些功能

網店應該只負責展示商品，創造購買但是在網店購買需要改變庫存狀態那么如何解決這個問題呢現在有很多解決方法，但是請告訴我真相

購買已經是一個足夠復雜的功能了它獲得訂單，檢查庫存以查看是否有可供購買的商品，執行支付并創建運輸這可能看起來只是另一個功能，但是由于它的大小，它可以很容易地被分成單獨的部分

我們制定了嚴格的庫存合同根據合同，我們可以得到所有貨物的清單和所有可用貨物的清單我們可以檢查這些貨物是否可以出售，并減少它們的數量網店只需要知道有貨就可以了如果我們決定支持軟刪除，或者在某一點上支持多個狀態，就像我們在上面的例子中所做的那樣，在線商店不需要知道這些變化只需更改網店收到的數據，在網店不知情的情況下，即可完成上述操作

我們需要為購買功能做同樣的事情合同要求完成購買的操作網店發起了這個操作，然后它的任務就完成了購買功能接管它檢查是否有可用的商品，然后如果一切正常，它就完成購買，并相應地減少庫存商品的數量

在整個系統中，我們已經清楚地將所有可以獨立存在的功能分開我們從庫存開始，所以它當然有自己的系統接下來我們增加了兩個功能，分別是網店和購買，可以獨立實現

我們確實有快遞服務，但是到目前為止整個過程都不需要知道它的存在所以我們也要把它當成一個獨立的系統我們不應該把它強行塞進現有的體系里，讓它們相匹配

好吧目前，我們還沒有一個具有許多復雜依賴關系的功能的系統我們有許多子系統，每個子系統都有特定的復雜性，它們共同構成了一個兼容且可持續的解決方案

結論

建立，維護和擴展軟件是一件復雜的事情一開始可能看起來很容易只是加了這個功能但是我們添加的東西越多，等式就變得越復雜如果我們想強迫太多的事情，最終我們會發現自己陷入了一個無法解決的問題兩者之間只有一線之隔

對于多體問題，我們可以盡可能的簡化系統，分成很多小的部分這些小問題很多人都能解決，比如小學生都能解決單項問題三體似乎沒有解決辦法但是，乍一看，這兩類問題的區別很小所以我們可以嘗試把它分解成幾個部分，用軟件設計的思想對問題做一些簡化的近似

原始鏈接: