原因：之前修改代碼看心情和工作量。後來接觸了一個小項目的重構工作，發現自己並沒有系統的重構邏輯。所以覺得有必要 去學習一下。所以選擇了上面說的兩本書。以下作為自己看書的領悟和記錄。 首先：為什麼重構？ 首先改善代碼易讀性，包括機器和人。 機器易讀性：提高性能，減少冗餘，分類清楚，保持健壯性的前提下盡 ...
原因：之前修改代碼看心情和工作量。後來接觸了一個小項目的重構工作，發現自己並沒有系統的重構邏輯。所以覺得有必要
去學習一下。所以選擇了上面說的兩本書。以下作為自己看書的領悟和記錄。
首先：為什麼重構？
首先改善代碼易讀性，包括機器和人。
機器易讀性：提高性能，減少冗餘，分類清楚，保持健壯性的前提下儘量堅持單一職責原則。善用繼承多態，提高代碼利用率。
人的易讀性：層次分明，規則明確，命名規範，儘量使方法短小易讀，善用封裝，減少方法複雜性，以及代碼復用性。
第一章：
閱讀第一個案例後總結：
- 分解重組。
把集成多個功能的方法分解，重組成多個方法。簡化方法，提高易讀性。
然後對應的方法，放到該放的位置，這點需要自己去判斷。
作者觀點：1.絕大多數情況下，函數應該放在它所使用的數據對象內部。2.重構最好小步前進，一步一步重構。避免犯錯。
關鍵字：Replace Temp with Query,From Template Method
2. 多態的使用。
註意switch。提取公共介面。這裡涉及到設計模式。當你使用switch的時候要註意了，可能這個點可能有重構使用多態的可能。
通過父類抽象一個方法，子類繼承父類返回不同的code實現switch case。方法放對位置是關鍵。
3.重構方式。
從小的地方開始，如一個方法，或者幾個屬性，慢慢延伸到整個類，整個功能以致整個項目。關鍵一點是，每一個小的改
動都需要我們寫對應的單元測試配合，保證代碼不會有很大的失誤。這樣才能保證整個項目重構完成後更穩定和健壯。
所以重構的過程就是：小修改->測試->小修改->測試....直到完成。
第二，三章 ：
重構原則和代碼的壞味道：
二：
1.何時重構，三次法則。一個東西反覆修改或者有問題三次，你就需要重構。加功能重構，修補bug時重構。覆審代碼時重構。
2.重構涉及到資料庫結構的時候比較麻煩。所以我們首先設計資料庫的時候需要認真謹慎。然後降低數據實體跟對象之間的耦
合性。一般方法中間增加一個分割層。降低修改成本。
3.修改介面時要特別小心。牽一發動全身，瞭解業務，完全掌握介面的調用者，可以修改。
4.實在代碼混亂不堪，花費時間比重寫還多，建議重寫。
三，代碼壞味道：
1Duplicated Code.重覆代碼。記得以前學習時候老師的一句話“Don't repeat yourself”。當你發現你在重覆你自己的時候，
說明代碼有點壞味道了。想辦法重新設計一下吧。
2.Long Method，過長函數。以前一個領導告訴我，一個方法不要超過多少多少行代碼。當時我不理解。後來我發現，
往往我們比較長的方法內部其實實現了好幾個功能。我為什麼不分開這些功能呢？分開後還可以更加方便代碼的重覆利用。
這是想起了大學老師講的單一職責了。
3.Large Class，太大的類。提煉新的類，細分不同的職責，這樣之後你會突然發現你的文件也許放的位置是正確的了。
然後你的項目也許就有了一些約定。
4.Long Parameter List,過長的參數列。方法代替參數去重構。得到想要的。如果沒法代替，想想依賴關係。
5.Divergent Change,發散式變化。說白了，就是多想想以後會有什麼功能過來，來的時候你需要做的多不多？或者
有矛盾。在這時候你需要考慮清楚。也許你覺得你後邊都考慮到了。那麼請抬高你的業務視野，放眼整個項目，或者放眼相
關項目。站的夠高業務越熟悉。這些才能想的越完善。用好Extract Class.
讀到這裡我發現第三章這些跟後邊的章節依賴性很強。有點長，所以下一篇接著寫吧。我先去理解去一下。
另：看書建議，最好配合設計模式去看。
