第一章：什麼是設計與結構
「架構」常被使用在高層次的事物中，與較低層次的細節脫節，而「設計」往往似乎隱含了較低層次的結構與決策。但作者舉了設計新家的建築師為例子，什麼是架構？外觀、挑高和空間及房間佈局。而每個插座、燈的開關和燈座在哪，是低層次的設計。
我看到了支持所有高層決策的全部細節
也看到了這些低層次的細節和高層次的決策都是房子整體設計的一部分
這兩者之間是沒有明確的界限的
目標
軟體架構的目標是最小化建置和維護「需求系統」所需要的人力資源。
在整個系統的生命週期中，如果花的 effort 都保持是少的，那麼這個設計就是好的。如果隨著版本變動而增加，那這個設計就是不好的。
案例
作者用投入的人力、時間、程式碼的行數來度量當例子，工程師的人數增加了，程式碼的行數卻慢慢收斂，每行程式碼的時間也耗費越來越大。
雖然這裡我不覺得必然是這樣，有時候程式碼的變動用行數來度量很容易有瑕疵（因為往往是邏輯上的轉變，但是行數沒有變化），但如果看每行所花的時間成本增加了，確實可以想像是，這些舊的程式碼不好修改，需要花大量的時間去理解，才能換上、增加新的功能。
什麼地方出了錯？
無論你用哪種時間尺度，製造紊亂的開發速度總是比保持整潔的開發速度還要慢
開發人員常常陷入一個熟悉的謊言：「我們可以晚點整理他，電我們只能先上市！」當然，一如往常的，之後永遠都不會被清理乾淨，因為市場壓力永遠不會減少。
而我自己在工作的時候也有深刻體會到這件事情，小時候軟體架構概念不好，後來想要開始修整。但是整個專案已經成長了數倍，「你看看！我 ~體內的~ 相依耦合而形成的怪物已經長這麼大了(愛心)」，而營收的壓力也襲擊而來，其實真的很難有時間去整理乾淨。即使你想站在專業的角度去拉扯，但是一站在另一個角度去思考....團隊資源就這些，不應該太過於分散。
想要走得快，唯一的方式就是要走的好。
然而，即使要重新設計擺脫舊有的紊亂，也要小心，不要過度自信而踏上後塵。
而這本書的內容，就是苗粟了什麼事好的整潔架構和設計(clean architectures and design)，這樣軟體開發人員就可以建構出對於生命週期長期有利的系統。
