Chapter 2  命名

• 命名要表現意圖
• 避免歧義和誤導，增強區分
• 命名可讀性：便於發音，增強印象，便於交流
• 命名可查性：增強區分，便於搜尋
• 類和物件的命名：名詞或名詞短語
• 方法的命名：動詞或動詞短語
• 使用僅表述單一概念的詞，如 get，避免多概念的詞，如 fetch
• 使用行業術語及業務術語

Chapter 3  方法

• 尺寸：越小越好，不應超過20行
• if、else、while 等 statement 不應超過一行
• 單一責任
• 單一抽象層級
• 無參最優，一引數次之，二引數最次，不應超過3引數，否則應引入引數結構或物件
• 避免將引數作為輸出

Chapter 4  註釋

• 儘量少用註釋，避免過時的註釋
• 如果能用良好的命名來表現意圖，就不用註釋
• 如果能用程式碼來表現意圖，就不用註釋
• 良好的註釋：　
  • 提供補充資訊
  • 解釋意圖
  • 警告
  • TODO 註釋
  • 強調註釋

Chapter 5  格式

• 垂直格式：
  • 單個類檔案，不超過100行/150行/200行
  • 使用空行分隔方法
  • 自頂向下的方法依賴分佈
• 水平格式
  • 單行不超過80字元/100字元/120字元，螢幕能夠全部顯示
  • 保持縮排
  • 使用空格，運算子左右使用空格等
  • 顯式地突出空迴圈，避免省略地寫為一行
  • 優先遵循團隊規定的格式

Chapter 6  物件和資料結構

• 資料結構和物件的對立性：
  • 資料結構以 public 暴露內部屬性，不提供訪問方法
  • 物件以 private 隱藏內部屬性，提供訪問方法
  • 資料結構易於增加新方法，同時不影響已有結構。物件反之，易於增加新類，同時不影響已有方法。
  • 資料結構不便於增加新資料結構，因為需要改變每個已有方法。物件反之，不便於增加新方法，因為需要改變每個已有類。
  • Law of demeter：最少知識原則，一個物件應對其他物件有儘量少的瞭解。類C的 f 方法，應只調用這些方法：
    • 類C的方法
    • f 創造的物件的方法
    • 傳遞給 f 的引數物件的方法
    • 類C的成員例項變數的方法

Chapter 7  錯誤處理

• 使用 exception， 避免使用返回的錯誤碼
• 逐層 throw exception，在最頂層 catch，即定義一個錯誤傳遞流
• 將 try/catch 抽取出來作為獨立函式
• 在需要時定義新的 exception 類
• 不要返回 null，定義一個 Null 類
• 不要傳遞 null

Chapter 8  邊界

• 在自己的程式碼和第三方程式碼的邊界處，使用自己編寫的程式碼適配（介面卡），避免將第三方程式碼直接嵌入自己的程式碼
• 測試第三方程式碼

Chapter 9  單元測試

• TDD
• 測試程式碼和生產程式碼同樣重要，但測試程式碼不一定需要遵循同樣的效率和資源限制
• 保持測試程式碼的clean，避免過時和冗餘等
• BUILD-OPERATE-CHECK 的測試模板
• given/when/then 的測試方法命名建議
• 模板方法模式可能有所幫助
• 每個測試方法，僅測試一個概念
• F-I-R-S-T原則
  • Fast，測試效率要高
  • Independent：每個測試應當獨立
  • Repeatable：在不同環境下均可執行
  • Self-Validating：應擁有一個boolean的輸出，自身直接輸出測試是否通過
  • Timely：每個測試應 just before 寫在生產程式碼之前

Chapter 10  類

• 類成員順序如下，自頂向下
  • public static constants
  • private static constants
  • private instance variables
  • public functions
  • 被 public function  呼叫的 private functions 緊跟在該 public function 之後，滿足自頂向下的閱讀順序
• 尺寸：類儘可能小，不同於用物理行數衡量方法的尺寸，應該用 responsibilities 衡量類的尺寸。類應保持單一責任。
• 類應該保持單一責任（SRP），而類名應該描述這一責任。
• 類名不應超過25個單詞，同時避免 if、and、or、but等代表多責任的詞，同時少用大範圍的含糊的詞，如super，manager等。
• 儘可能提高類的內聚度：儘量使類中的每個成員變數被類方法使用
• 將大類分隔為很多小類，優化組織性，提高內聚。但也會造成類數量的激增。
• 依賴倒置原則（DIP），類依賴於抽象，而不是具體實現。降低耦合。
• 將類中會變化的部分抽象出來，讓客戶程式碼依賴於抽象，而不是具體實現。

Chapter 11  系統

• 將系統構造部分，與使用部分解耦
• 將構造和初始化部分，全部放在main函式中，再在main函式中，將構造完畢的物件，以引數形式傳遞給具體使用它們的函式。這是一個方法。
• 工廠方法可能有所幫助。
• 依賴注入（DI）和控制反轉（IoC）機制可能有所幫助。
• （這一章沒怎麼看懂）

Chapter 12  迭進

• Kent Beck 認為的“Simple Design”的四條規則。重要性由上而下遞減。
  • 執行所有測試
  • 無重複（良好重構）
  • 表現程式設計者意圖
    • 良好命名
    • 保持類和方法儘可能小
    • 遵循公有標準和共同語言，如通用規範、設計模式等
    • 良好的單元測試 
  • 最小化類和方法的數量
    • 經過去重、重構等操作之後，類和方法的數量可能激增。因此在此基礎上，儘量減少它們的數量。

Chapter 13  併發

• 複雜且不成熟，跳過。