More Related Content
Similar to 重構—改善既有程式的設計(chapter 4,5) (20)
More from Chris Huang (19)
重構—改善既有程式的設計(chapter 4,5)
- 2. 4.1 – 自我測試碼的價值 重構需要測試,一個可靠的測試環境 花一整天(甚至更多)只找出一隻小小臭蟲 每個class都應該有一個測試函式 確保所有測試都完全自動化 每個測試應該從嘗試讓測試出錯(紅燈)->測試通過(綠燈)->最後才重構(Refactor) 一整組測試能夠大大縮減收尋臭蟲所需時間
- 3. 4.2 – JUnit測試框架 頻繁地執行測試,每天至少執行每個測試一次 JUnit的圖行使用介面(GUI) 單元測試和功能測試的差別 每當接獲bug report,請先撰寫一個單元測試來揭發這隻臭蟲 重構過程中可只行少數幾個測試,主要檢查當下正在整理的程式碼
- 4. 4.3 – 添加更多的測試 編寫未盡完善的測試並實際執行,好過對完美測試的無盡等待 考慮可能出錯的邊界條件,集中火力 檢查預期的錯誤是否如期出現 不要因為無法捕捉所有臭蟲就不寫測試碼 花合理時間抓出大多數的臭蟲,要好過窮盡一生抓出所有臭蟲
- 6. 5.1 – 重構的記錄格式 每個重構手法都有如下五個部分: 名稱(name) – 建造一個重構詞彙表 概要(summary) -此重構手法適用情景 動機(motivation)– 為何需要這個重構,和何時不該使用這個重構 作法(mechanics) – 一步一步介紹如何進行 範例(examples) – 舉例說明如何運作
- 7. 5.2 – 尋找引用點 不要盲目地「搜尋 ─ 替換」 強型別語言中可尋求編譯器的協助,進而找出被吊掛的引用點 在繼承中宣告,或被覆寫多次的函式時,編譯器會迷或 編譯器可能太慢,可先使用文字收尋工具,最後再利用編譯器做復查的動作 編譯器無法找到經由反射機制(reflection)而得到的引用點
- 8. 5.3 – 這些重構準則有多成熟 重構的基本技巧 ─ 小步前進、頻繁測試 ─ 本書的準則是作者自己使用重構的記錄。 是在「單行程」(single-process)軟體這一大前題下考慮並介紹它們的 設計範式(Design Patterns)為你的重構行為提供了目標 運用重構的時候,這本書提供的僅僅是一個起點。希望各位也開始發展屬於自己的重構手法