整潔架構（1）簡介
最近開始做一些軟體架構的工作，覺得自己對於軟體架構的知識比較匱乏。同事推薦了這本"Clean Architecture ---A Craftsmans Guide To Software Structure And Design". 評價非常高，內容很經典，我就系統的學了學，原著是英文的，市面上並沒有中文版。我就邊度英文原著，邊做了一些中文的讀書筆記。
事實上，架構就是設計，他們之間沒有什麼區別。就像房子的建築師，要設計房子的尺寸布局和形狀等等。
架構的目標是什麼？
一個烏托邦式的描述:
軟體架構的目標就是最小化為了構建和維護軟體系統所需的人力資源
列舉一些事實:
一個市場主導的軟體產品，所產生的代碼量逐年上升
當然對於程序員來說，他們每天都很努力，然而生產率也確實在下降。
如果你比較了圖5和圖2，你就會發現，開始的時候幾百美元就可以買來許多功能代碼，而到了最後，2百萬美元基本什麼都沒有買到。任何一個CFO看到這兩幅圖，都會知道，立即要做些什麼來組織這場災難！
2600年前的龜兔賽跑故事，闡述了一個道理：
通俗一點講就是，不圖快，但求穩！
Jason Gorman做了一個有趣的實驗, 他編寫了一個整數變羅馬數字的簡單程序。然後他每天只花費30分鐘來做這個實驗。第1,3,5天，他採用了TDD(test-driven), 第2,4,6天他選擇不採用任何策略的寫代碼。其中的效率圖表如下圖：
所以結論就是：
正因為這樣，我們需要開始認真的談論軟體架構的質量了。
任何軟體系統，都提供兩種不同的價值：Behavior和Structure.
軟體開發者應該負責確保兩個價值都保持很高。不幸的是，他們總是注重一個而忽略另一個，甚至兩個都忽略了。這樣的話，軟體系統就沒有了相應的價值。
Behavior
這是軟體第一個價值。程序員被僱傭來編寫機器的行為方式來掙錢，並滿足顧客需求。我們幫助stakeholders來開發功能規範或者需求文件。然後通過寫代碼來滿足客戶的需求。
當機器違背了這些需求，程序員就需要通過debug來修復問題。
許多程序員覺得這就是他們所有的工作。他們相信他們的工作就是讓機器來實現需求並修復bugs。很悲哀，他們錯了。
架構Architecture
軟體必須"軟". 也就意味著，軟體應該很容易被改變。當客戶改變了他們的想法，這些改變應該可以簡單和容易去實現。
新的變化的需求越來越難去適應已有的構架，因為系統的形狀越來越難匹配需求的形狀。
問題當然就出在於構架。一個構架如果越喜歡一種形狀，那麼越多的 新feature就越難添加進來。因此構架應該是無關形狀的。
中國老子有句古話：大象無形。表示宏大的方正（形象）一般看不出稜角。也應該就是這個意思吧。
更重要的價值
到底是功能更重要還是構架更重要。不同的人可能說辭不同。
但是事實是，如果你給我一段程序，運行得很好，但當需求改變時，他不可能被修改。那麼這段程序就是沒有用的。
對於軟體架構師的挑戰是更加艱巨的。架構師創建一個架構，允許features and functions可以被容易的開發，修改和擴展。
推薦閱讀：
