Clean Architecture讓系統穩定演化

April 25 15:40~16:26

劇情

以下是許多開發團隊都經歷過的對話…

技術控員工：我們的系統架構太爛，我已經快受不了了。現在新技術那麼多，如果用了這些新技術所有問題都迎刃而解。我強烈建議，應該把系統砍掉重練。

技術主管：我承認我們的系統已經改不太動，每次修改的成本越來越高，但我覺得我們應該重構系統而非重新撰寫系統。

技術控員工：理論上沒錯，但我們系統亂成一團，重構不一定比重寫要來得簡單啊，搞不好更花時間。現在新技術、新框架，解決我們的問題很快，我還是覺得應該要整個砍掉重練。

技術主管：根據我以前的經驗，整個砍掉重練風險很高。我們的系統至少目前可以動，這是無可取代的價值。我還是覺得重構比較保險，穩扎穩打。

技術控員工：可是我已經不想再看到這堆爛code了，有辦法你自己來重構看看。

技術主管：!@#!%^^#!E04…

***

不自覺的過程

技術控員工與技術主管各有道理，雖然一般來講重構比重寫要來得好，但有時候歷史包袱太大，很可能重寫的成本反而比重構要來得低。決策的困難點在於，兩種做法的成本很難量化之後加以比較，只能藉由經驗、資源、甚或是一時情緒衝動所決定。依據主管的經驗，重寫往往沒什麼好下場，只滿足技術控員工學習新技術的慾望，而忽略的重寫帶來的高風險。

如何讓系統在持續演進的過程中，又可以保持一定的穩定性，相信是很多軟體從業人員想要追求的目標。上禮拜四地震後Teddy跟指導教授聊天，聊到Alexander在《Notes on the Synthesis of Form》提到：「一個系統要能夠持續保持穩定，其自身的調適性一定要大於外在需求改變的頻率與強度，否則系統將會處於不穩定的狀態。」

在傳統社會中，因為文化的限制力道非常大，因此建築物的演化，往往只做小範圍的改變，除非發生文化劇烈改變（例如維新運動、被外族統治），否則設計者基本上只要遵循老祖宗的做法去設計建築即可。

此外，因為設計者（蓋房子的人）生活在其設計的建築物之內，所以只要建築物有任何不合適的地方，例如漏水、淹水、通風不良等，設計者立刻會著手修正。因此，系統會一直保持穩定的狀態。這種設計方法，叫做不自覺的過程（unselfconscious process），此過程會產生極其穩定的系統。

***

Clean Architecture所形成的文化

不自覺過程的原理，套用在軟體系統一樣成立。以一個套用Clean Architecture的系統為例，Clean Architecture好比傳統社會的文化，規定了系統階層（entity、use case、interface adapter、framework and driver、）、每個階層所負擔的責任、以及限制（相依性原則、跨層原則）。

在此文化之下，開發人員不再享有「我想怎麼胡搞瞎搞，就怎麼胡搞瞎搞的自由。」相依性原則嚴格限制了系統相依性方向，I/O層變成可隨意替換的一部分。框架不再是架構師關心的核心，domain model與use case才是主角。

開發人員透過持續重構讓軟體系統隨時維持在clean code、clean architecture的狀態，系統的調適性便可基本大於需求改變的頻率與強度，如此才可讓「需求改變主要與scope相關，與改變發生的時間點無關」，軟體就真的軟了起來。

你不喜歡React，想換成Angular，沒問題，把UI層抽換掉即可，它原本就是可插入替換的一部分。不喜歡MySQL想換成NoSQL資料庫，沒問題，換個database gateway即可。

***

結論

只要你的軟體系統的調適性大於需求改變所造成的殺傷力，你就不怕需求改變所造成的衝擊。就算改變會造成混亂，也可以在短時間內讓系統恢復穩定。

這不是開發人員一味只強調技術至上的觀點，而是一種支持快速交付商業價值的靈活性。

***

廣告

對於Clean Architecture + 領域驅動設計（Domain-Driven Design；DDD） + 測試驅動開發（Test-Driven Development；TDD）有興趣的鄉民， 歡迎參考泰迪軟體的【Clean Architecture這樣學就會了實作班】課程。

***

友藏內心獨白：限制讓開發變得更容易。