三體問題和軟件開發有什麼關係？_風聞

撰文 | Krste Šižgorić

翻譯 | 藏痴

審校 | Nuor

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

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

三體問題

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

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

冥王星—冥衞一系統的側視圖，顯示出冥王星繞着它外面的一點公轉丨來源：維基百科

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

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

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

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

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

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

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

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

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

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

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

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

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

位於不等邊三角形頂點的三個初始速度為零的相同物體的近似軌跡丨來源：維基百科

回到單體問題

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

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

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

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

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

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

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

簡化問題

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

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

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

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

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

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

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

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

結論

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

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

本文經授權轉載自微信公眾號“中科院物理所”，原標題為《三體，但是寫軟件》。

原文鏈接：

https://krste-sizgoric.medium.com/the-three-body-problem-in-software-development-74adeda6807c

特 別 提 示

1. 進入『返樸』微信公眾號底部菜單“精品專欄“，可查閲不同主題系列科普文章。

2. 『返樸』提供按月檢索文章功能。關注公眾號，回覆四位數組成的年份+月份，如“1903”，可獲取2019年3月的文章索引，以此類推。