前陣子終於將經典書重構-改善既有的程式的設計完完整整練習過一次
在這邊紀錄一下重點與看法 文末附上我練習過程的程式碼
原書範例使用JAVA，我使用C#重新改寫書上的範例
書籍介紹：重構-改善既有的程式的設計-第二版
為Refactoring：Improving The Design of Existing Code的中文翻譯書
重構的定義
不改變外在的行為的前提下，對程式碼做出修正，以改進程式的內部結構。本質上來說，重構就是在程式碼寫好之後改進它的設計
重構的原則
- 需要有穩定且堅固的測試機制
- 以微小步伐修改程式，如果引入錯誤便可以很容易發現
- 如果覺得比較困難增加新的功能，就先重構後再增加
- 只有寫出人類容易理解的程式碼，才是優秀的程式員
兩頂帽子 - 重構與增加新功能
- 重構：不能增加新功能，只管修改程式結構。只在絕對必要的時刻才修改測試。
- 增加新功能：不應該修改既有程式碼，只管增加新功能以通過測試
如果增加新功能很困難，那就先重構它
為何要重構?
- 改進軟體設計：一個主要的方向就是
消除重複的程式碼。 - 使軟體更容易被理解：提高可讀性。
- 幫你找到Bug
- 幫你提高編程速度
我的看法： - 藉由練習的過程中，我覺得重構還可以提升自己寫code的技巧
- 我有使用Resharp進行重構，同時也掌握了工具的使用技巧，所以是有提升我的開發速度的
何時重構?
- 三次法則：事不過三，三則重構
- 增加功能的時候重構
- 修改錯誤的時候重構
- Code Review的時候重構
重構的現實
- 不知道如何重構
- 如果這些利益是需要長時間才能展現的，何必現在付出努力? 長遠看來，當專案收穫這些利益的時候，或許自己已經不在職位上了
- 程式碼重構是額外的工作，老闆付錢給你，是要你增加新功能
- 重構可能破壞現有程式
我的看法：站在企業的角度，重構對企業來說無法實質獲得收益，對很多公司來說，產品程式碼只要會動就好，不管是不是寫得不好維護。但從另一個角度來說，程式碼不好維護、不易讀會造成程式開發人員花了更多的時間去解bug、理解程式碼，這些都是隱性成本。但對程式開發人員來說，大規模的重構或許不是那麼容易可以執行，但我們可以從小地方開始做起，一小步一小步的改善。
可以仿效童子軍法則：離開營地時比剛來的時候乾淨-程式碼簽入時比剛簽出的時候更為完善
如何重構，在哪裡重構
- 使用自動化工具來識別哪裡需要重構，以及提供重構的建議
我的看法：Resharper是一套不錯的重構工具
安全的進行重構
- 相信自己的編碼能力
- 相信編譯器會捕捉遺漏的錯誤
- 相信測試套件能捕捉你和編譯器都遺漏的錯誤
- 相信程式碼複審(code review)能捕捉你、編譯器、測試套件都遺漏的錯誤
我的看法：有測試案例保護來進行重構會比較安心一點
安全重構的侷限性
- 程式員有可能犯錯
- 有編譯器無法捕捉的錯誤，特別是與繼承相關的作用域錯誤
- 無法保證測試套件涵蓋所有可能情況
- 程式碼複審人員可能無法徹底檢查別人的程式碼
學習重構的方法
隨時挑一個目標：某個程式碼開始發臭，就應該將問題解決掉。你應該朝目標前進，達成後就停止。
我的看法：記得要有測試案例保護才可以開始進行沒把握就停下來：你無法證明自己所做的一切還能夠保持程式的原意，就停下來，有改善的成果就發布，沒有的話就撤銷。
我的看法：一次一小步的重構與改善，確定沒有改壞之後就發布。學習原路返回：當重構已經失控時，要果斷放棄，回到上一個測試可以通過的程式碼版本。
我的看法：一定要使用版本控制系統來搭配二重奏：兩人結對重構，你的搭檔會看到與想到你沒發現的東西，當你的夥伴不知道你在重構什麼東西，通常自己也會不知道在重構什麼。在重構之前先與夥伴討論目標與方向，這樣夥伴才能指出你的錯誤。
書上介紹了很多程式碼的壞味道(Bad Smell)，以及要採用哪些方法修改
我都寫在我的Github專案上，每一個方法都有一些簡介，還有我練習的過程
就請大家自行參考囉，希望能幫助到你