1. 行為準則

2. 需求的不確定性

2.1. 不斷變化的客戶需求

2.2. 軟體項目無法避免的挑戰

2.3. 產品需求和環境會隨著時間的推移而改變，你的應用程式也必須隨之改變

2.4. 不斷變化的需求會導致不穩定性，使開發工作偏離軌道

2.5. 通過構建可演進的架構來適應不斷變化的需求

2.5.1. 可演進的架構可避免複雜性，複雜性是演進性的敵人

2.5.2. 矛盾的是，在軟體中實現簡潔性會很困難

3. 複雜性

3.1. 複雜系統的特點

3.1.1. 高依賴性

3.1.1.1. 致軟體依賴於其他的API或代碼行為

3.1.1.2. 依賴性顯然不可避免，甚至是可取的，但必須取得平衡

3.1.1.3. 高依賴性的系統很難修改

3.1.1.3.1. 它們有緊密的耦合性和高度的變更放大效應

3.1.1.3.2. 緊密的耦合性是指那些嚴重依賴彼此的模塊，它們導致了更高的變更放大的倍率，即某項單一的變更也需要修改依賴關係

3.1.1.4. 深思熟慮的API設計和有節制地使用抽象模型將最大限度地降低緊耦合性和變更放大效應

3.1.2. 高隱蔽性

3.1.2.1. 使得程式員很難預測某項變更的副作用、代碼的行為方式，以及需要修改的地方

3.1.2.2. 晦澀的代碼需要更長的時間來學習，開發人員更有可能在無意中破壞某些東西

3.1.2.3. 癥狀

3.1.2.3.1. “知道”太多的對象

3.1.2.3.2. 鼓勵副作用的全局狀態

3.1.2.3.3. 掩蓋代碼的過度間接定址

3.1.2.3.4. 影響程式遠程行為的遠距離操作

3.1.2.4. 採用具有明確的約定和標準模式的API可以減少隱蔽性

3.1.3. 高慣性

3.1.3.1. 指軟體保持之前的使用習慣

3.1.3.2. 用於快速實驗且很容易被丟棄的代碼具有低慣性

3.1.3.3. 一項為十幾個關鍵業務應用提供驅動力的服務具有高慣性

3.1.3.4. 複雜性的成本隨著時間的推移而增加，所以高慣性、高變化的系統應該被簡化，而低慣性或低變化的系統可以保持複雜（只要你拋棄它們或繼續讓它們保持不變）

3.2. 複雜性不總能被消除，但你可以選擇把它放在哪裡

3.2.1. 向後相容的變更可能使代碼使用起來更簡單，實現起來卻更複雜

3.2.2. 用於解耦子系統的間接層可降低依賴性，卻會提高隱蔽性

4. 可演進的設計

4.1. 面對未來未知的需求策略

4.1.1. 試圖預判未來的需求

4.1.2. 建立抽象模型作為逃生艙門，使後續的代碼修改更容易

4.1.3. 都會導致複雜性提高

4.2. KISS的原則

4.2.1. 要保持事情簡單一些

4.2.2. 使用KISS記憶法，記住要以簡單性為核心原則構建系統

4.2.3. 簡單的代碼可以讓你在未來增加系統的複雜性

4.3. 保持代碼簡單的最簡單的方法之一是避免什麼代碼都要寫出來

4.3.1. 告訴你自己，你不是真的需要(You ain’t gonna need it，YAGNI)

4.3.2. 要使用最小驚訝原則和封裝原則

4.4. 不要構建你不需要的東西

4.4.1. 靠猜測而編寫出來的代碼會繼續使事情陷入困境，它需要被維護，開發人員需要理解它，它必須被構建和測試

4.4.2. 避免過早優化，避免不必要的靈活抽象模型，以及避免最小可行產品(minimum viable product，MVP)所不需要的產品特性

4.4.3. 過早優化是指開發人員在證明需要優化之前就對代碼進行性能優化

4.4.4. 靈活的抽象模型——插件式架構、封裝介面和通用數據結構（如鍵值對）是另一種誘惑

4.4.4.1. 抽象自有代價：它把實現的代碼框在僵硬的邊界里，而開發者最終會與之抗爭

4.4.4.2. 靈活性也使代碼更難以閱讀和理解

4.4.4.2.1. 保持代碼靈活性的最佳方法之一是減少代碼的總量

4.4.4.2.2. 蒙茨法(muntzing)，將使你的軟體保持“苗條”和適應性

4.4.5. MVP允許你先測試一個想法，而不必押寶在某項成熟的實施上

4.4.5.1. 在你懷疑可以插入優化的地方放置介面填充程式，但不要真正實現它們

4.5. 最小驚訝原則

4.5.1. 不要讓用戶感到驚訝，構建特性表現得要像用戶最初期望的那樣，具有上揚的學習曲線或奇怪表現的特性會使用戶感到沮喪

4.5.2. 不要讓開發者感到驚訝，令人驚訝的代碼通常晦澀難懂，這會導致複雜性

4.5.3. 通過保持代碼的針對性、避免隱性知識，以及使用標準類庫和模式來消除驚訝

4.5.4. 凡是開發者在調用API時需要知道的但又不屬於API本身的不明顯的知識，都被視為隱性知識

4.5.5. 排序需求決定了某些動作必須按照某種特定的順序進行

4.5.5.1. 使用文檔來說明某些排序需求是種好辦法，但最好是一開始就沒有這個排序需求

4.5.6. 當一個方法的簽名暗示了比該方法實際可以接受的有效輸入範圍更廣時，就會出現隱藏的參數需求

4.5.7. 切記讓參數需求具體化和可視化

4.5.7.1. 使用可準確適配約束的特定類型，當使用靈活的類型如JSON時，考慮使用JSON schema來描述預期的對象

4.5.8. 使用標準類庫和開發模式

4.5.8.1. 請使用慣用的代碼風格和開發模式

4.6. 封裝專業領域知識

4.6.1. 將軟體組件映射到業務領域，將使代碼的變化保持專註和乾凈

4.6.1.1. 會計、計費、運輸等

4.6.2. 封裝的領域自然會傾向於高內聚和低耦合

4.6.2.1. 理想的特征

4.6.2.2. 高內聚和低耦合的軟體更容易演進，因為變更的“爆炸半徑”往往更小

4.6.2.3. 解耦的代碼是自成一體的，對其邏輯的改變不需要對其他軟體組件也進行改變

4.6.3. 開發人員經常以“層”為單位來思考軟體：前端、中間層和後端

4.6.3.1. 每一層都有獨立的團隊，會增加協調成本，因為每一項業務邏輯的變化都會影響到所有的軟體分層

4.6.4. 識別領域邊界和封裝領域知識既是一門科學又是一門藝術

4.6.4.1. 領域驅動設計(domain-driven design，DDD)，它定義了一套廣泛的概念和實踐，將商業概念映射到軟體上

4.6.4.2. 只有在最複雜的情況下才需要全覆蓋的DDD

4.6.4.3. 熟悉DDD將有助於你做出更好的設計決策