又一個實戰類型的章節，主要講如何讓測試完整的覆蓋代碼
這本書越到後面翻譯的越是起飛，這一章的英文標題是 Emergence ，完全不知道這個譯者爲啥會自造一個詞來實現翻譯 譯者想表達的意思可能是迭代+進化 12.1 通過迭進設計（ Emergent Design ）達到整潔目的
介紹一些保持軟件邊界（和其他接口對接的界限）整潔的實踐手段和技巧 8.1 使用第三方代碼 第三方程序包和框架提供者追求 普適性 ，這樣就能在多環境中工作，吸引廣泛的用戶 使用者則想要集中滿足特定需求接口 接口提供方和接口使用
通過對一個命令行參數解析程序的講解來體現整潔代碼的實現過程 代碼內容太長，而且後面的代碼排版出現了問題，沒有仔細看 14.1 Args 的實現 編程是一種技藝甚於科學的東西 要編寫整潔代碼，必須先寫出骯髒代碼，然後再清理它的
測試是簡單的驅動式程序，讓我們能夠手工與自己編寫的程序交互 9.1 TDD 三定律 在編寫不能通過的單元測試前，不可編寫生產代碼 從測試的角度考慮代碼實現 只可編寫剛好無法通過的單元測試，不能編譯也算不通過 只可編寫剛
對整本書中提到的優化手段做了一系列總結 17.1 註釋 17.1.1 不恰當的信息 註釋只應該描述對應代碼和設計的技術信息，不要說廢話 17.1.2 廢棄的註釋 廢棄的註釋會遠離它們曾經描述的代碼，更有可能這些代碼早已經
還是認爲這一章中作者對於註釋的態度有點過於理想了，所以內容僅供參考 Tips 若編程語言足夠有表達力，或者我們擅長用這些語言表達意圖，就不那麼需要註釋，也許是根本不需要 我認爲，如果註釋能夠清晰的表達代碼的含義，對於回顧一
錯誤處理只不過是編程時必須要做的事之一，當錯誤發生時，程序員就有責任確保代碼照常工作 7.1 使用異常而非返回碼 遇到錯誤時，最好拋出一個異常，這樣調用代碼時就會更簡單，也就更簡潔，其邏輯不會被錯誤處理搞亂 7.2 先寫
要做到真正整潔的代碼，至少要將注意力上升到類的層面 10.1 類的組織 根據標準的 Java 約定，類的標準組織應該如下所示 public class ClassName { // 公共靜態變量 // 私有靜態變
整潔代碼的層次繼續上升，從類到系統，本章講解如何在較高的系統層級上保持代碼整潔 11.1 如何建造一個城市 系統和城市一樣，有些人負責全局，其他人負責細節，幾乎不可能一個人掌控所有 11.2 將系統的構造與使用分開 軟件
整潔的併發編程是個複雜話題，這一章我看完收穫不是很多，因爲直到目前爲止都沒有怎麼涉及過併發編程 13.1 爲什麼要併發 併發是一種解耦策略，可以把 做什麼 和 什麼時候做 區分開 做什麼相當於 目的 什麼時候做相當於 時機
分析了一段 Junit 代碼，相當於一次小實戰 這種代碼解析類型的內容確實不適合 Kindle 看 15.1 Junit 框架 Junit 的基礎代碼是 Kent Beck 和 Eric Gamma 在飛機上花三小時寫出來的
