本篇核心重點是什麼？

軟體架構的目標是最小化建制和維護“需求系統“所需要的人力資源

我覺得值得紀錄的重點

1. 軟體架構的目標是最小化建制和維護“需求系統“所需要的人力資源
這句話是本書的核心中的核心，後續幾章會提到需多觀念和方法，所有的一切都是為了，讓大家建立起整潔的意識，和磨練撰寫有乾淨整潔的code，達成這上述的目標

2. 你把大部分時間用在，管理爛攤子，還是在創造新價值？
書中有附上，多張長條圖，其中一張是顯示每行程式碼的成本，橫軸是發佈的版本，縱軸是公司所花費的金錢成本，結論是發佈的版本越多，公司所耗費的成本呈現急劇上升，作者用來表達，初期不重視架構，寫了一堆難以維護的髒code，導致開發到後來，工程師開發新功能成本越來越高，多數寶貴精力都浪費在理解或是管理爛攤子，而非開發具有價值新功能

3. 晚點，晚點我就來整理髒code，先能work就好？ 然後髒code變成地雷，送給同事
是的！我先承認，我總是有這樣的想法，冒上心頭，尤其在追deadline的時候，當然我知道這會變成地雷，當然我也很想要寫的乾淨整潔，但是後有需求方的追殺，難道你要跟他說，請等一下，讓我把這裡優化一下？ 更甚者，人生還有更重要的事，例如下班？不能等啊
上述是承認自己，目前沒有能力一開始就寫好code，但是至少要求自己，確實做到“回頭擦乾淨，清潔一下程式碼”的承諾，自己的地雷，自己拆，不然就這樣發佈出去，別人不說自己都覺得丟臉．

所以我給自己立下的規則，這對我來說，至少是真正可行的

• 開發前，做好80%規劃，畫好藍圖，至少在開發的時候是流暢的
• 允許一開始寫髒code，但是根據時程緊迫程度，最快一天，最慢週五，要完成清潔

4. 想走得快，唯一的方式是要走的好
簡單說要做有效率開發，就必須非常自律，寫個乾淨整潔的code，注重架構，如此才能做到“用最小資源，做開發”．不要期待後續再來整理的乾淨，是不可能的
我的想法是，整個團隊，可以持續要求自己做有品質的開發，並且要求自己持續精進整潔力，並且持續有意識的發現不適當的架構，並且安排時間進行優化，因為事實是，寫乾淨的code，是需要大量的實作經驗的，如此才能夠辨識“髒”，且寫出有品質的code，這對一個人來說，就很有挑戰，何況是幾十人的團隊呢？

總結來說

我覺得本篇，作者指出一個方向，並說明邁向那個目標基本的心法和觀念，我看完之後，自己會比較有概念自己應當確實做到哪些事情，才能更接近目標，就像給你一把尺，讓你開始有能力去衡量自己的每一次開發的行為