代碼結構之間的關聯是隨時間推移逐漸形成的，因為我們將不同的部分視為整體的一部分，在實際操作中，我們應盡量避免這樣做。

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

三體問題

為了解釋三體問題以及它和軟件開發的聯系，讓我從單體問題開始解釋。單體問題更常被稱為有心力問題（the central-force problem）。有心力問題試圖決定一個受到中心力作用的粒子的運動狀態，這個有心力的力源位置固定。更直白地講，恒星可以視為靜止的。行星的運動可以用三角函數表示。

考慮稍微復雜一點的情況，讓我們想象兩個有質量的物體通過引力互相影響彼此的運動狀態，也就是二體問題。這可以被用來描述地球和月球圍繞對方做的運動。或者舉一個更好的例子，冥王星和冥衛一，就像下面動圖描述的一樣。

冥王星—冥衛一系統的側視圖，顯示出冥王星繞著它外面的一點公轉。（維基百科）

對于包括引力在內的許多種力來說，廣義的二體問題可以被轉化成兩個單體問題，因此二體問題可以完全求解。因此，二體問題也存在著對應的解決方案。

但如果我們再加入一個有質量的物體，將整個系統轉變為三體問題，那么事情就變得不可預測起來，常常陷入混亂。對于絕大多數初始條件，三體問題不像單體或二體問題那樣有一般的封閉解。

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

三體問題與軟件開發有什么關系呢？事實上并無關系。但如果思考這兩件事，我們可以發現它們有相似之處。彼此影響的強耦合的功能與極弱耦合功能可以在同一個系統中和平共存，而不會迫使其中之一發生改變。讓我們將軟件開發與n體問題做一個比較。

最開始事情很簡單而且易于理解。我們有一個主角，也就是一個中心，其他所有事情都圍繞它展開。軟件功能不多，不會彼此沖突。

比如，我們打算開發一個庫存管理應用。我們需要做的只是插入新條目、增刪數量以及了解庫存狀態。所以我們完成了這些功能。

過了一段時間我們需要添加新東西。最好能開一家網店來線上售賣產品。因此我們開始為庫存管理軟件添加新功能。

首先，要添加一個網頁。我們獲取包含可用數量的庫存狀態。現在這個網頁需要描述可用庫存的狀態，但這并不意味著這些原本可用的商品不在庫存中了，它們只是換了一種狀態。所以我們需要在庫存中設置一種新狀態。我們需要掌握“現貨”狀態的商品數量，以及“可售”狀態的商品數量。

但是現在需要更改為網店獲取可用數量的操作，以反映這一變化。如果我們不能賣掉它們，那么倉庫里到底有多少商品其實并不重要。我們只想在網店展示“現貨”數量。我們需要再次修改網店。

系統中一部分物體的重力吸引其他部分改變運動狀態。這兩部分之間存在競爭，直到二者達到穩定狀態。一旦我們優化了功能，事情就會回到最初可預測的狀態。所有事情都按計劃運行，這讓我們很高興。我們仍然可相對容易地預測接下來會發生什么，并知道一個部分的改變會如何影響其他部分。

兩個質量有“微小”差別的物體繞共同的質心運動（維基百科）

但事情可以被優化。我們可以為顧客提供快遞服務。因此我們檢查了現有的系統，并在每一步都做出改變。快遞服務改變了庫存，庫存改變了網站設計，網站又反過來改變了快遞服務，快遞服務改變了庫存……

快遞服務擴展了商業貿易。一個倉庫不再能滿足需求，我們希望在更多地方發展生意，并且系統需要能支持這種工作方式。但這將如何影響現有的系統？庫存需要調整以適應多個地點。而由于網站會減少庫存的商品數量，它也需要被改造以支持多個地點。但怎么做到這些呢？這又要求庫存和快遞服務也做出改變……好混亂啊。

位于不等邊三角形頂點的三個初始速度為零的相同物體的近似軌跡（維基百科）

回到單體問題

我們該如何避免這個問題？我們有怎樣才能避免某一個功能對其他功能產生嚴重影響？

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

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

設想如果我們試圖計算未來十年復活節的日期。復活節是一個基督教節日，在每年春分后第一個月圓夜后的第一個周日。當我們計算這些日期時，我們真的在意木星的79個衛星嗎？當然不，我們也不必這么做。

我們把軟件開發的解決方案分解成許多小部分，讓每一部分都圍繞著“太陽”運行。這里的“太陽”可以是信息中介、服務總線、或者只是已經建立好的契約（接口）。我們決定我們的“太陽系”需要多大程度的解耦。環繞太陽運動的小部件是模塊、域還是微服務并不重要，重要的是部件之間要盡可能地獨立。這會讓它們更容易被理解。用這種方式計算復活節日期甚至不需要知道木星有79個衛星。

月亮顯著地影響了地球的軌道，這是事實。如果我們關心太陽和地球的關系，那么我們并不是在談論地球和月亮環繞太陽的軌道，我們只是在談論地球的軌道。無論一個功能多么復雜（比如木星有79個衛星），在整個系統（比如太陽系）中我們只需要將它們視為一個整體。

用這種方法我們并不需要處理太陽系中（大約）一百二十萬個天體，也不需要處理大約700個行星、小行星或衛星。我們只考慮八大行星。因為一般而言，當我們談論太陽系時，我們只關心這八大行星。盡管這樣計算結果并不完美，但對我們來說已經足夠精確，不會在工作中帶來問題。

簡化問題

當我們考慮一個倉庫的庫存，我們到底在考慮什么？或許是一個大的倉庫和里面存儲的許多貨品。倉儲的工作是什么？為了存儲商品直到被它們被賣出。我們的軟件系統應該只考慮這些功能。

網店應該只負責展示商品并創建購買。但網店中的購買需要改變庫存狀態。所以如何解決這個問題？現在有很多解決方法，但請恕我直言。

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

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

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

縱觀整個系統，我們已經清晰地分開了所有可以獨立存在的功能（一些而不是另一些）。我們是從庫存開始的，所以它當然有自己的系統。接下來我們添加了“網店”和“購買”兩個可以獨立實現的功能。

我們確實有快遞服務，但目前為止整個流程并不需要知道它的存在。所以我們也應該將其視為一個獨立系統。我們不應該把它強行加入已有的系統中并讓它們相匹配。

好了。現在我們還沒有一個有著許多有復雜依賴性的功能的系統。我們有許多子系統，每一個子系統都有特定的復雜度，它們共同構成了一個相容并可持續的解決方案。

結論

建立、維護并擴展軟件是一件復雜的事。最開始可能看起來很容易。“只是添加這個功能而已。”但是我們添加的東西越多，方程就變得越復雜。如果我們想強行加入太多東西，最終我們會發現自己陷入了一個無法解決的問題中。而二者之間只有一線之隔。

對于多體問題，我們可以盡量簡化系統，把它分成許多小部分。有很多人都可以來解決這些小的部分，比如小學生都可以解決單體問題。三體問題看起來無解，然而，這兩類問題之間的差異乍一看卻很小，因此可以利用軟件設計的思路，嘗試化整為零，對問題做一些簡化近似。

審核編輯：劉清