均為原創，讀架構整潔之道的筆記。
包含了部分自己的理解，包含了原書中至少70%的知識點。
完整筆記，各位老哥友鏈加起來吧。
我的部落格地址：www.yuque.com/_huangkuan
引言
設計與架構之間的區別到底是什麼？什麼是設計？什麼又是架構？
該書的重要目標就是清晰的，明確的對這兩者進行定義和解釋。該書認為，這兩者，即設計和架構，沒有任何區別！
架構這個詞往往用於高層級的討論中，而設計往往涉及到的是底層細節。但是一個真正的架構師的日常工作來看，這樣的區分是不成立的。
如設計一個新房子，一個合格的設計師不止要設計房子的地基，外型外觀，房間佈局，我們還可以看到設計師的設計圖紙中，也充斥著大量細節，如每個插座，開關的具體位置，甚至是使用材料的大小明細規格等。
總的來說，是這些細節設計共同支撐了頂層的架構設計（即細節和頂層是不可分割的），底層的設計資訊和頂層的架構設計，共同組成了整個房屋。
軟體設計也是如此，是高層級和底層細節共同定義了整個軟體系統。所謂的底層和高層本身就是一系列決策組成的連續體，並沒有清晰的分界線。
目標是什麼
好軟體設計的終極目標：用最小的人力成本來滿足構建和維護該系統。
判斷：如果軟體系統的整個生命周內一直能維持低成本，就說明系統是優良的。如果每一次釋出都會提升下一次變更的成本，那麼設計就是不好的。
案例分析
這裡的案例，體現了一個不好的設計。
專案初期，軟體的版本迭代和程式設計師人數呈上升趨勢，正相關。但是隨著軟體版本的提升，前期版本的生產效率有明顯提升，後期生產效率的提升卻非常緩慢。
這中間即出現了差值，即程式設計師人數多了，後期效率卻很低。並且版本的提升，往往帶來的是程式碼變更成本的提升，程式碼變更成本的提升曲線幾乎等同於程式設計師人數的增長趨勢。
最終案例中第8代的產品的構建成本，要比第一代產品高出40倍。那麼該產品的盈利是否又有40倍呢？顯然這種模式是不可持續的。
亂麻系統的特點
上述案例，這種系統通常是沒有經過設計，匆匆忙忙被構建起來的，為了加快釋出速度，然後增加人手，同時加上決策層，對程式碼質量和設計結構的長期忽視，才會造成這種結果。
從上面的例子中，還可以得出一個結論，開發者的生產效率，會隨著版本提升越來越低，並且修改成本越來越大。
這對開發者來說是非常具有挫敗感的，因為並沒有人在偷懶，大家都在努力發版，完成工作。他們大部分時間都是在修修補補，小部分時間才是完成新功能。
管理者視角
這種系統不僅給開發部門帶來問題，從管理者角度來講，開發部門的薪資待遇支出在不斷提升，甚至追上了公司利潤的提升速度和比例。解決這個問題刻不容緩。
問題到底在哪裡
關鍵點在於軟體研發工程師的過度自信和錯誤觀點：
- 持續低估良好的設計和整潔程式碼的重要性。
- 欺騙自己：”我們可以未來再重構程式碼，產品上線最重要”，但結果是永遠不會有那一天，因為市場的壓力永遠也不會消退，競爭永遠在進行中，作為先上線的產品，後面會有很多對手追趕，只有比他們更快才能領先。
- 糟糕的程式碼和設計如果能夠加快上線速度，那麼是可以被接受的。但是他們忽略了一個規律，無論是長期還是短期，胡亂編寫程式碼的工作速度其實比循規蹈矩更慢。
作者舉了一個實驗案例，這個案例讓兩個人在6天內完成同一個功能，以程式碼均透過一個測試集，視為成功透過。其中一個人採用TDD方法程式設計，另一個則從頭開始編寫，結果是採用TDD方法的速度更快。
這個實驗案例揭示了一個開發核心特點：要想跑得快，先要跑得穩。
管理者扭轉局面的唯一選擇，就是扭轉開發者的觀念，讓他們改變上述錯誤觀點，為自己構建的系統負責。
當然，某些軟體研發工程師會認為，拯救的辦法就是重構。但是這裡仍然沒有逃離過度自信。試問如果是他們得錯誤觀點和過度自信導致目前的狀況，那有什麼理由相信他們重構的系統，結果會更好？
過度自信只會使得重構設計陷入和原專案一樣的困局中。
本章小結
研發團隊最好的選擇是清晰的認識錯誤觀點和避開過度自信，開始對自己的程式碼架構負責，對質量負責。
要想提高質量，首先需要知道什麼是優秀的軟體架構。為了提高生產力，有需要先了解系統架構的各個屬性和成本與生產力的關係。
該書為讀者描述了什麼是優秀的，整潔的軟體架構。
個人總結
以上這些我都經歷過。要想改變這種開發局面，在如今的大環境中，需要軟體研發團隊的每一個人都清楚的認識到那些錯誤觀點，為自己的程式碼負責，同時也需要研發領導頂住壓力，以合適的方式向老闆闡述軟體研發的精髓與匆忙上線的後果。
我也會想如果把這個系統重構就好了，但是無論是同事還是領導都曾對我說，老闆不會同意的，這太花時間了，並且短期內沒有額外產出。可是當前系統就是因為這幾年來，每次匆忙上線，才造成如今變更成本大的局面。如果剛開始我們都學習了軟體架構，頂住了壓力，或許今天就會好一些。
本作品採用《CC 協議》，轉載必須註明作者和本文連結