簡單易懂讀《重構》

簡單易懂讀《重構：改善既有代碼的設計》

用自己語言去精煉作者的思想。儘量把精華和重點整理出來，文章持續更新，可能部分章節會經常改動，由於文章持續優化，不同章節格式和表述方法會略微不同。某些翻譯與原書可能不同。

---

哪些代碼需要重構

• Duplicated Code(代碼重複):在多個地方出現做相同事的代碼。
• Long Method(方法內代碼過長):一個函數(方法)裏做的事過多過雜，代碼很長
• Large Class(臃腫的類):單個類幹了太多的事，代碼量過多
• Long Parameter List(入參過多):函數中的入參過多
• Divergent Change(類中的多面手):修改和擴展代碼時造成同一個類不斷的需要被修改
• Shotgun Surgery (牽一髮而動全身):牽一髮而動全身，由於某種變化造成過多相關類進行修改。
• Feature Envy(移情別戀):函數比起自身所在類的數據，更加依賴於其他某個類的數據。
• Data Clumps(一團糟的數據):多個類中重複出現的字段，或多個函數(方法)中相同的入參。
• Primitive Obesession (零散的數據項):代碼中的零散的數據值過多
• Switch Statements (複雜繁冗的switch語句):switch語句過多或過複雜
• Parallel Inheritance Hierarchies(繼承中的粘連):每當爲一個類增加子類時，必須也爲另一個類相應增加子類。
• Lazy Class (多餘的類):多餘出來的類或者隨着程序更迭失去大部分原有意義的類。
• Speculative Generality (被高估的擴展性):高估未來的擴展性，添加過多不必要的類，方法或繼承體系
• Temporary Field (臨時變量):某個實例變量僅爲代碼中一小部分功能臨時所用而創建
• Message Chains (調用鏈過長):代碼中的調用鏈過長，造成代碼耦合。
• Middle Man (不必要的委託關係):類中的函數存在過度委託給其他對象的情況
• Inappropriate Intimacy (類間關係過於緊密):兩個類間總是試圖訪問對方的過多屬性
• Alternative Classes with Different Interfaces (異曲同工的類)：做了相同工作，命名卻不同的方法。
• Incomplete Library Class (不完美的庫類):封裝好的類庫中功能不能滿足實際需求
• Data Class (純數據的類):POJO(或javaBean)類
• Refused Bequest (逆反的子類):子類不需要父類的某些方法，字段，或不需要實現父類實現的接口。
• Comments (不恰當的註釋):比起寫註釋，有時不如通過重構減少不必要的註釋。

如何開展重構

按照如下格式記錄，有助於重構工作的開展，以下是重構提綱

1. 重構名稱
2. 概要
3. 動機
4. 做法
5. 範例

重構建議

• 不要試圖一蹴而就，重構需要一次又一次的做優化。
• 不要試圖省略測試過程，連續或者過多的一次性重構太多代碼，容易引起難以排查的代碼漏洞或bug。
• 多利用IDE等工具的重構相關功能或插件。
• 和別人一起重構可以收到更好的效果
• 多與領導和同事溝通重構的必要性

重視自測試的價值

養成寫單元測試的習慣

推薦重構網站

比起這個博客，推薦大家直接看這個網站，簡單明瞭一看就懂，比我總結的還簡單粗暴。
https://www.refactoring.com/catalog/

體會

體會：

1. 有收穫，希望有時間一定讀一下原書,作者對重構講的很系統和具體。
2. 個人覺得本書翻譯，想翻譯的文藝一些結果搞得讀不懂或者讀的難受，比如"狎暱"，恕本人文化低，我讀都讀不來，更別說含義了，當時還是用筆畫輸入法纔打出來到搜索引擎查詢。
3. 句子也感覺翻譯有點生硬，有種沒有重新根據中文語義來組織句子的感覺。本書以java語言爲例，但是翻譯計算機名詞時卻採用了非java通用說法，比如method在java上一般譯爲方法而不是函數,看起來比較彆扭。