軟體複雜度與分而治之

軟體技術發展的使命之一就是控制複雜度(complexity)。從高階語言的產生，到結構化程式設計，再到物件導向程式設計、元件化程式設計等等。關於複雜度的定義並不一致，想要詳細了解的可以讀讀the many faces of complexity in software design.

英文中complex和complicated有著微妙的不同。但總結起來，軟體複雜度偏負面意義，包括兩個要點:

- 難以理解 (難以維護和擴充套件。)

- 無法**行為

複雜度是隨著軟體規模不斷擴大而必然產生的。它本身又是乙個相對的概念，同乙個系統對於設計者、開發者，以及維護者而言，複雜度是不同的。不同時期，乙個程式設計師所能掌握的複雜度也是不同的，這也是乙個程式設計師不斷提公升的目標。

既然業界已經對抗複雜度幾十年了，我們就來整理一下。

以分解的方式進行的設計，主要特點是:

- 分離職責(seperation of concerns,參考單一職責原則)

- 關注介面(定義互動)

這是最常使用的技術了。將乙個大問題，不斷的拆解為各個小問題進行分析研究，然後再組合到一起。在西方稱為divide and conquer principle (分而治之原則)。

在結構化程式設計的時代，提倡模組化(modularization)。最早提出軟體複雜度的工程師提出了基於元件的軟體(component based software)。不知道是不是從樂高積木上得到的啟發，將系統中拆分為不同的元件，各自實現，然後再組裝在一起。

在架構設計中，無論是c/s風格，分層，還是n-tier,soa，和前面元件式一樣，都是在進行分解,它們都更加強調組合互動。設計上，分分職責，定義好介面，就可以各自開發了。然後將互動限定於介面層，就能夠很好的控制整個系統的複雜度。

比如應用層使用乙個語音庫(speech library,乙個以庫的形式的模組化應用), 根本不用關心其內部實現，只要了解如何使用它的api就可以了。