Ch2. 兩個價值維度 每個軟體系統都為利益相關者(stakeholders)提供兩種不同的價值維度：行為(behavior)與結構(structure)。軟體開發人員負責確保這兩種價值保持高水準。不幸的是，他們往往只關注其中一個而忽略另一個，更不幸的是，他們往往只關注較低價值的那一個，最終使軟體失去價值。
行為 歉體的第一個價值來自於行為。程式設計師被聘請來使機器以一種能為利益相關者帶來獲利或節省成本的方式運作。我們透過協助利益相關者制定功能規格或者需求文件，然後編寫程式碼，使利益相關者的機器滿足這些需求。當機器違反這些要求時，程式設計師便開始除錯以修復這些問題。
結構 軟體的第二個價值來自於結構，軟體之所以為「軟」體，是因為它被創造出來是為了方便改變機器的行為。為了實現其目的，軟體必須要有足夠的彈性，易於修改。當利益相關者對某項功能改變主意時，這種改變應該要是可以簡單且容易進行的。進行這種改變的困難程度應該只與改變的範圍成比例，而不是與改變的形式成比例。
然正是範圍和形狀之間的差異常常推動軟體開發成本的增長。這就是為什麼成本與所需求的變更規模不成比例。這也是為什麼開發前期比開發後期便宜得多的原因。
從利益相關者的角度來看，他們只是提供了一系列大致相似範圍的變更。從開發者的角度來看，利益相關者給予他們一系列拼圖碎片，他們必須將其放入日益複雜的拼圖中。每個新的要求都比上一個更難擬合，因為系統的形狀與要求的形狀不匹配。
我在這裡以一種非傳統的方式使用「形狀」這個詞，但我認為隱喻很貼切。軟體開發人員常常感覺自己被迫將方形木塊塞進圓洞中。
問題當然在於系統的架構。如果這個架構偏好某種形式，那麼新功能愈來愈難以適應這種結構。因此，架構應該盡可能地不受形式的限制。
更大的價值 行為與架構，何者提供更大的價值？對軟體系統來說，它的功能更重要，還是易於修改更重要？
如果你問企業經理，他們通常會說軟體系統的工作更重要。開發人員通常也會贊同。但這是錯誤的態度，我們可以用簡單的邏輯工具來證明它是錯誤的，那就是檢查極端情況。
如果你有一個完美運作但無法更改的程式，那麼當需求改變時它將無法運作，意謂著這個程式將變得沒有用處；然而一個不起作用但容易修改的程式，那麼我們可以透過簡單的修改使其運作起來，並在需求變化時保持運作，因此這個程式將持續保持有用。
也許這個論點對有些人來說不那麼具有說服力，畢竟沒有什麼程式是真的不能改變的。但是，有些系統在實際上是幾乎不可能改變的，因為改變的成本大過於了改變的好處。許多系統在某些功能或配置上達到了這一點。
如果你問企業經理們是否希望能夠進行變更，他們當然會說是，但可能會在回答中指出目前的功能比任何後續的靈活性更重要。相反地，如果企業經理們向你提出變更要求，而你估計的成本過高而無法負擔，他們很可能會對你允許系統達到變更變得不切實際的程度感到憤怒。
艾森豪威爾矩陣 下圖為艾森豪威爾(Dwight D. Eisenhower)總統的重要性(importance)與緊迫性(urgency)的矩陣，艾森豪是這麼說的：
我有兩種問題，一種是緊急的，一種是重要的。緊急的問題並不重要，而重要的問題從不緊急。
軟體的第一個價值 - 行為，是緊迫但並非總是特別重要。
軟體的第二個價值 - 架構，重要但從不特別緊迫。
當然，有些事情既緊急又重要，或有些事情既不緊急又不重要。故最終，我們可以將這四種問題安排成優先順序：
緊急且重要 不緊急但重要 緊急但不重要 不緊急也不重要
需要注意的是，程式碼的架構位於前兩個位置，而程式碼的行為則佔據第一與第三的位置。商業經理和開發人員常犯的錯誤是將第三位的事項提升至第一位。換句話說，他們未能將那些緊急但不重要的功能與真正緊急且重要的功能區分開來。這種失誤導致忽視系統的重要架構，而偏好系統中不重要的功能。
軟體開發人員面臨的困境是，商業經理無法評估架構的重要性。這就是軟體開發人員被聘用的原因。因此，軟體開發團隊有責任強調架構的重要性，而不是功能的緊迫性。 為架構而戰 履行這個責任意味著投入一場戰鬥，或者也許更好的詞是「奮鬥」。坦白說，這些事情總是這樣做的方式。開發團隊必須為他們認為對公司最好的事情而奮鬥，管理團隊、市場團隊、銷售團隊和運營團隊也是如此。這總是一場奮鬥。
有效的軟體開發團隊會毫不畏懼地與其他利益相關者平起平坐地爭論。請記住，作為一名軟體開發者，您也是一個利益相關者。您需要保護您所需的軟體。這是您的角色和責任的一部分，也是您被雇用的重要原因之一。
如果你是一位軟體架構師，這個挑戰對你來說尤其重要。軟體架構師根據他們的工作描述，更關注系統的結構而非其特性和功能。架構師創建一個架構，使得這些特性和功能能夠容易地開發、修改和擴展。
只要記住：如果架構放在最後，那麼系統的開發成本將會愈來愈高，最終對系統的某個部分或整個系統的變更幾乎變得不可能。如果這種情況發生，那意味著軟體開發團隊沒有為他們知道的必要事項進行足夠的努力。
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的日子還快。
結論 在每一種情況下，最好的選擇是開發組織要認識到並避免自己的過度自信，並且開始認真對待軟體架構的質量。
要認真對待軟體架構，你需要知道什麼是良好的軟體架構。為了構建一個設計和架構能夠最大程度減少工作量並提高生產力的系統，你需要知道哪些系統架構的特性能夠達到這個目標。
這本書就是在談這個，它描述了好的乾淨架構和設計的樣貌，讓軟體開發者能夠建立具有長期盈利生命力的系統。
採用好的軟體架構可以大大節省軟體項目構建與維護的人力成本。讓每次變更都短小簡單，易於實施，並且避免缺陷，用最小的成本，最大程度地滿足功能性和靈活性的要求。
Clean Architecture
A Craftsman’s Guide to Software Structure and Design
中文翻譯: 無瑕的程式碼 - 整潔的軟體設計與架構
原著: Robert C. Martin(Uncle Bob)
目錄 第一部分 概述 第1章 - 設計與架構到底是什麼 第2章 - 兩個價值維度 第二部分 從基礎構件開始: 程式設計範式 第3章 - 程式設計範式總覽 第4章 - 結構化程式設計 第5章 - 物件導向程式設計 第6章 - 函數式程式設計 第三部分 設計原則 第7章 - SRP 單一職責原則 第8章 - OCP 開放封則原則 第9章 - LSP 里氏替換原則 第10章 - ISP 介面隔離原則 第11章 - DIP 依賴反轉原則 [第四部分 組件構建原則)(/clean_arch/sec4) 第12章 - 元件 第13章 - 元件聚合 第14章 - 元件耦合 第五部分 軟體架構 第15章 - 什麼是軟體架構 第16章 - 獨立性 第17章 - 劃分邊界 第18章 - 邊界剖析 第19章 - 策略與層次 第20章 - 業務邏輯 第21章 - 尖叫的軟體架構 第22章 - 整潔架構 第23章 - 展示器和謙卑物件 第24章 - 不完全邊界 第25章 - 層次與邊界 第26章 - Main 元件 第27章 - 服務: 宏觀與微觀 第28章 - 測試邊界 第29章 - 整潔的嵌入式架構 第六部分 實現細節] 第30章 - 數據庫只是實現細節 第31章 - Web 是實現細節 第32章 - 應用程式框架是實現細節 第33章 - 案例分析: 影片銷售網站 第34章 - 拾遺