1. Ch4 – 構築測試體系 （Building Tests)

2. 4.1 – 自我測試碼的價值 重構需要測試，一個可靠的測試環境 花一整天（甚至更多）只找出一隻小小臭蟲 每個class都應該有一個測試函式 確保所有測試都完全自動化 每個測試應該從嘗試讓測試出錯(紅燈)->測試通過(綠燈)->最後才重構(Refactor) 一整組測試能夠大大縮減收尋臭蟲所需時間

3. 4.2 – JUnit測試框架 頻繁地執行測試，每天至少執行每個測試一次 JUnit的圖行使用介面(GUI) 單元測試和功能測試的差別 每當接獲bug report，請先撰寫一個單元測試來揭發這隻臭蟲 重構過程中可只行少數幾個測試，主要檢查當下正在整理的程式碼

4. 4.3 – 添加更多的測試 編寫未盡完善的測試並實際執行，好過對完美測試的無盡等待 考慮可能出錯的邊界條件，集中火力 檢查預期的錯誤是否如期出現 不要因為無法捕捉所有臭蟲就不寫測試碼 花合理時間抓出大多數的臭蟲，要好過窮盡一生抓出所有臭蟲

5. Ch5 – 重構名錄 （Toward a Catalog of Refactorings)

6. 5.1 – 重構的記錄格式 每個重構手法都有如下五個部分： 名稱(name) – 建造一個重構詞彙表 概要(summary) -此重構手法適用情景 動機(motivation)– 為何需要這個重構，和何時不該使用這個重構 作法(mechanics) – 一步一步介紹如何進行 範例(examples) – 舉例說明如何運作

7. 5.2 – 尋找引用點 不要盲目地「搜尋 ─ 替換」 強型別語言中可尋求編譯器的協助，進而找出被吊掛的引用點 在繼承中宣告，或被覆寫多次的函式時，編譯器會迷或 編譯器可能太慢，可先使用文字收尋工具，最後再利用編譯器做復查的動作 編譯器無法找到經由反射機制(reflection)而得到的引用點

8. 5.3 – 這些重構準則有多成熟 重構的基本技巧 ─ 小步前進、頻繁測試 ─ 本書的準則是作者自己使用重構的記錄。 是在「單行程」(single-process)軟體這一大前題下考慮並介紹它們的 設計範式(Design Patterns)為你的重構行為提供了目標 運用重構的時候，這本書提供的僅僅是一個起點。希望各位也開始發展屬於自己的重構手法