Ch1. 設計與架構到底是什麼？
對初學者而言，設計(Design) 與架構(Architecture) 基本上是沒有差別的。
「架構」這個詞常常用在高層次的情境，而與低層次的細節脫節；而「設計」則更常用於暗示著低層次的結構和決策。但事實上底層的細節與高層次的架構往往是伴隨而生的。（作者以建築設計作為範例，在建築設計圖中，會包含房屋形狀、外觀設計、高度、房間佈局等等，但同時也具備大量的設計細節，如每個插座、開關以及每個電燈具體的安裝位置，甚備某個開關與所控制的電燈的具體連接訊息等等。）
總而言之，底層設計細節和高層架構資訊是不可分割的。它們共同定義了整個軟體系統，缺一不可。所謂的底層和高層本身就是一系列決策組成的連續體，並沒有清晰的分界線。
目標是什麼？
- 軟體架構的終極目標是，用最小的人力成本來滿足構建和維護該系統的需求。
一個軟體架構的優劣，可以用它滿足用戶需求所需要的成本來衡量。如果成本很低，並且在系統整個生命週期內一直都能維持這樣的成本，那麼這個系統的設計就是優良的。反之如果該系統的每次發布都會提升下一次變更的成本，那麼這個設計就是不好的。
案例分析
下面為書中的一個真實案例，該案例中的數據均來源於一個匿名的真實公司。
- 該公司的工程人員數量的增長
由圖可見，人員的增長肯定是顯示了產品重大的成功。
2. 該公司同一時段的生滻力
從第二張圖可以發現一些端倪，雖然開發者愈來愈多，但程式碼的增長似乎接近了一個漸近線。
3. 隨著時間推移每行程式碼的成本
從第三張圖可見，成本快速的增加，大量地消耗利潤，將公司推向停滯，甚至是完全崩潰的境地。
凌亂系統的特點
當系統匆忙地拼湊在一起，當程式設計師的數量成為唯一的驅動力，而沒有考量程式碼的整潔度與設計結構時，必定會走向醜陋的結局。
- 每次版本發布的生產力
這張圖顯示了開發人員對這條曲線的看法。一開始的生產力接近100%，但隨著每次發布，生產力逐漸下降，最後趨近於零。
從開發者的角度來看，真是令人沮喪，因為每個人都在努力工作，但實際上已經無法完成更多。所有努力都被轉移到處理混亂上了，而不是開發新功能。
管理層視角
- 每次版本發布時的薪資支出
由圖明顯可見，後期投入的資金幾乎沒有帶來任何東西。但其中發生了什麼問題呢？
問題到底在哪裡？
現代的程式開發者，大腦中有一部分是在沉睡的，儘管它們知道「好的、乾淨的、設計良好的程式碼是重要的」。
這些程式開發者通常相信一個熟悉的謊言：「我們可以之後再整理，我們現在更需要趕快上線。」實際上是，在未來，程式從來不會被整理，因為市場上的壓力永遠不會減輕。所以開發人員從來不會切換模式，他們無法回頭整理事情，因為他們被逼著完成下一個任務，一而再再而三。於是混亂愈來愈多，生產力逐漸趨近於零。
程式開發者還相信一個更大的謊言：「沒有秩序的程式碼可以讓他們在短期內快速前進，且只會在長期才會反應出速度的變慢」，他們認為可以在未來的某個時刻從製造混亂轉換成整理混亂，但事實是，無論使用哪種時間尺度，製造混亂總是比保持整潔更慢。
- 完成任務所需的時間(With TDD/No TDD)
圖6是傑森戈爾曼(Json Gorman)進行的一個實驗。傑森在六天的時間內反覆進行這項測試，每一天他會完成一個整數轉羅馬數字的簡單小程式，當他通過了他預定義好的ATDD(Acceptance Tests)，他可以清楚知道他完成了程式。在過去六天內，每天的任務都花不到30分鐘。在第一、第三、第五天使用了 TDD(Test Driven Development)，而另外三天則沒有遵守。結果顯示，後期工作完成速度比前期快，而在實施 TDD 的日子裡，工作進展大約比沒有實施的日子快了 10%，即使是最慢的TDD日子也比非TDD的日子還快。
結論
在每一種情況下，最好的選擇是開發組織要認識到並避免自己的過度自信，並且開始認真對待軟體架構的質量。
要認真對待軟體架構，你需要知道什麼是良好的軟體架構。為了構建一個設計和架構能夠最大程度減少工作量並提高生產力的系統，你需要知道哪些系統架構的特性能夠達到這個目標。
這本書就是在談這個，它描述了好的乾淨架構和設計的樣貌，讓軟體開發者能夠建立具有長期盈利生命力的系統。