軟體開發的核心-控制複雜度

4 人贊了文章

最近重讀了《代碼大全》這本書, 書中包括的內容非常多, 從軟體設計, 代碼開發,到 團隊管理都有涉及,更像是一個軟體編程領域的百科全書. 但是,對於書中提到的一點印象最為深刻, 其實在 《人月神話》和《卓有成效的程序員》這兩本經典的書籍中都有提到, 那就是:

軟體設計與開發的核心就在於 控制複雜度

這句話的核心其實包括兩個問題:

• 軟體開發的本質問題性難題為什麼是 複雜度 ？
• 如何可以一定努力的降低我們軟體系統的複雜度 ？

雜耍拋球

其中, 書中對於軟體設計必須控制複雜度的解釋原因, 使用了一個非常 有意思的比喻 - 雜耍拋球, 書中的描述如下

你可以把它想做是一種心理上的雜耍( 邊拋邊接: 通過輪流拋接使兩個或者兩個以上的物體同時保持於空中), 程序要求你在空中保持的(精神上的)球越多,你就越可能漏掉其中的某一個, 從而導致設計或者編碼上的錯誤

—《代碼大全》

當我讀到這一段的時候, 感覺這本書的作者真是說出了軟體開發者心中的痛啊! 這段話也可以說是整本書的一個核心, 其實《代碼大全》這本書的所有部分都是在圍繞『如何降低軟體開發中的複雜度』這個觀點而論述的.

其實, 作者用這種, 雜耍拋球的方式非常形象的比喻了, 我們的大腦（生物結構上）本質的局限性導致的. 曾經美國人有一個非常有名的調查, 人類的大腦短期記憶能夠容納最多的不連續信息數就是7,加而或減二

具體可以參考心理學上被引用最多的一篇論文之一 魔數七, 加二或者減二: 人類處理能力的局限性(The Magical Number Seven). 而現實問題域中，我們要處理的變數何止是7! 所以我們根本不可能同時讓這麼多變數一起出現在我們大腦中, 我們大腦的內存其實是非常小的, 這是我們大腦的本質的局限性所導致的.

沒有銀彈

另外從哲學的角度來說, 柏拉圖認為, 任何事物都有 兩個屬性: 本質屬性 與 偶然屬性. 通過本質的屬性我們可以真正的區分不同事物，但是偶爾的屬性並不能. 通過此原則, 我們可以將軟體行業遇到的問題也分為兩類, 那麼軟體開發過程中 本質性的 難題是什麼?

《人月神話》的作者認為, 軟體行業中遇到的非根本問題(偶然屬性)都會隨著時間發展，技術的提升，會逐步解決. 但是 開發中的根本性問題 - 對於現實複雜世界本質的概念的複雜性是無法降低的. 書中寫到:

一個軟體系統有大量的狀態，存在大量不同元素的相互疊加。 這使得軟體系統的複雜性以指數的形式增長。而且，這些複雜度是軟體系統的根本屬性， 而不像數學和物理中那樣可以建立簡化的模型而忽略複雜的次要因素。

《人月神話》中對於本質的複雜性無法避免, 起了一個名詞, 日後基本成了這個行業的通用語: 沒有銀彈. 作者認為, 不要期望通過一種 萬能葯 能解決軟體開發中所遇到的複雜性問題,複雜性不可避免. 所以 當每次一種新的 編程原因/技術框架/開發模式 等出現的時候, 當有些人大喊可以顛覆以前軟體開發中的所有問題的時候的時候, 你就要小心了. 心理默默的告訴自己, 沒有銀彈! 沒有銀彈! 沒有銀彈！(重要的事情說三遍)

降熵

其實，軟體開發中的複雜度從某種意義上, 也可以用物理學第二定律來理解. 物理學第二定律又叫做 熵定律:

自然過程中，一個孤立系統的總混亂度（即「熵」）不會減小。

換成是軟體行業的背景就是, 用《程序員修鍊之道》裡面的解釋就是:

軟體的熵總是傾向於最大化的，程序員們稱之為「軟體腐爛」。

如果, 我們的開發過程中, 不要容忍任何『破窗戶』，低劣的設計/錯誤決策/糟糕的代碼,發現一個立即解決, 如果留下，他們會擴散，直至讓你的整個系統崩潰.

程序員只有在開發過程中,也只有通過不斷的外部做功, 不斷主動性的思考和重構你的代碼, 通過外部系統注入能量,來降低整個軟體系統的熵, 是整個軟體系統有序的狀態.

為此軟體開發行業提出了一些列的原則和指導方法, 重構 / 單元測試/ 模塊化設計 / KISS原則/ 面向介面編程/ 模式設計/ 分散式系統等等如此, 其實你都會發現, 這些方法和指導原則,根本都是 告訴程序員, 在軟體開發的過程中, 通過這些方法降低軟體系統整體的複雜度, 以便後期更好的維護與開發. 當軟體複雜度可以得到很好的控制，而不是讓軟體的熵無限的增長, 那麼這個軟體系統的壽命也就會很長,更容易後期的維護與擴展.

所以, 我們知道:軟體開發中的本質難題是 複雜度, 那麼我們在之後開發中 應該時刻的主動思考和做功: 如何通過不斷的代碼重構降低整體的複雜度. 保持我們的代碼熵的最小化.

最後，讓我們的代碼 永垂不朽 ！