第四章 注釋
第五章 格式
第六章 對象和數據結構
得墨忒耳定律 (最少知識原則)
1.每個單元對于其他的單元只能擁有有限的知識：只是與當前單元緊密聯系的單元；
2.每個單元只能和它的朋友交談：不能和陌生單元交談；
3.只和自己直接的朋友交談。
火車失事代碼
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
混雜
一半是對象，一半是數據結構，這是一種糟糕的設計。它增加了添加新函數的難度，也增加了添加新數據結構的難度。
隱藏結構
既然取得路徑的目的是為了創建文件，那么不妨讓 ctxt 對象來做這件事：
BufferedOutputStream bos = ctxt.createScratchFileStream(classFileName);
第七章 錯誤處理
1、別返回null值。程序中不斷的看到檢測null值的代碼，一處漏掉檢測就可能會失控。返回Null，作者認為這種代碼很糟糕。建議拋出異常 或者返回特定對象（默認值）。更早的發現問題。同理，也應該避免傳遞Null值給其他的方法。
2、在大多數的編程語言中，沒有良好的方法能對付由調用者意外傳入的null值。我們發布產品應該有容錯的機制，程序不能輕易的就崩掉，有異常應該及時記錄下來或給出提示。
第八章 邊界
1、通過接口管理第三方邊界，可以使用ADApter模式將我的接口轉換為第三方提供的接口。這個是要注意，第三方的代碼和自己的代碼混合太多，這樣不便管理。
第九張 單元測試
敏捷和TDD運動鼓舞了許多程序員編寫自動化單元測試，單元測試是確保代碼中的每個犄角旮旯都如我們所愿的工作。
TDD三定律
- 除非這能讓失敗的單元測試通過，否則不允許去編寫任何的生產代碼。
- 只允許編寫剛好能夠導致失敗的單元測試。 （編譯失敗也屬于一種失敗）
- 只允許編寫剛好能夠導致一個失敗的單元測試通過的產品代碼。
整潔的測試 具有 可讀性
構造-操作-檢驗（BUILD-OPERATE-CHECK）測試代碼三個步驟
每一個測試一個概念
F.I.R.S.T 整潔的測試遵循以下5條規則：
1.快速（Fast） 測試應該能快速運行，頻繁運行測試，就能今早發現問題
2.獨立（Independent）測試應該相互獨立。某個測試不應為下一個測試設定條件，可以單獨運行每個測試，及以任務順序運行測試。
3.可重復（Repeatable）測試應該可在任務環境中重復通過。
4.自足驗證（Self-Validating）測試應該有布爾值輸出。不應該手工對比量不同文件來確認測試是否通過。
5.及時（Timely）測試應該及時編寫。單元測試應該恰好在使其通過的生產代碼之前編寫，如果在編寫生產代碼之后編寫測試，你會發現生產代碼難以測試。
