本附錄彙整本書最重要的設計原則與紅旗，作為設計與審查時的快速參考。
設計原則彙整#
以下是書中討論過、最重要的軟體設計原則：
- 複雜性是逐步累積的：必須在意每一個小細節
- 能跑還不夠：程式可運作只是底線
- 持續、小額地投資改善系統設計
- 模組要深
- 介面應為最常見用法設計得最簡單
- 模組擁有簡單介面比擁有簡單實作更重要
- 通用模組更深
- 把通用與特殊用途的程式碼分開
- 不同層次應有不同抽象
- 把複雜性向下拉
- 把錯誤（以及特殊情況）從定義中消除
- 設計兩次
- 註解應描述程式碼看不出的事
- 軟體應為易讀設計，不是為易寫設計
- 開發的增量單位應是抽象，不是功能
紅旗清單#
以下任一徵兆出現在系統中，都暗示設計可能有問題：
淺模組（Shallow Module）#
類別或方法的介面並不比其實作簡單多少。
資訊洩漏（Information Leakage）#
某個設計決定被反映在多個模組中。
時序分解（Temporal Decomposition）#
程式結構建立在「操作執行的順序」上，而非資訊隱藏。
過度暴露（Overexposure）#
某 API 強迫呼叫端為了使用常用功能、必須先學習極少用到的功能。
穿透型方法（Pass-Through Method）#
一個方法幾乎只把參數轉送給另一個簽章類似的方法。
重複（Repetition）#
同一段非平凡程式碼一再出現。
通用 / 特殊混合（Special-General Mixture）#
特殊用途程式碼未與通用程式碼乾淨分離。
連體方法（Conjoined Methods）#
兩個方法依賴緊密到「不看另一個就無法理解這一個的實作」。
註解重複程式碼（Comment Repeats Code）#
註解中的所有資訊都能立刻從旁邊的程式碼看出。
實作文件汙染介面（Implementation Documentation Contaminates Interface）#
介面註解中描述了使用該實體不需要知道的實作細節。
模糊名稱（Vague Name）#
變數或方法名涵蓋範圍太廣，無法傳達有用資訊。
難以命名（Hard to Pick Name）#
很難為某個實體取出精確且直覺的名字。
難以描述（Hard to Describe）#
要把某變數或方法描述完整，文件必然冗長。
不顯而易見的程式碼（Nonobvious Code）#
一段程式碼的行為或意義無法被快速看懂。
使用方式#
把本附錄當作設計檢查清單：
- 寫新模組時，自問是否符合每條設計原則
- Code review 時，掃過紅旗清單
- 看到任一紅旗 → 停下來思考是否有更簡單的設計
隨著你經常使用這份清單，你會內化它們，最終不需要查就能直覺辨識出設計問題。