前言：最近做一個特性，參照原有邏輯增加某個功能，老代碼本身存在兩套相似的流程，再添加上一套流程后，發現代碼的重復度及其的高，基本可以理解為一套框架流程復制出來3個類，給3個功能使用，我對比了每個類的代碼后，發現代碼重復度基本在50%以上，這種代碼真是越寫越爛的感覺，于是費力的做了一下重構，搞了個父類出來，抽取了大部分公共函式，整體代碼看著就舒服多了，草草做了下重構后，突然覺得自己并不系統的知道要如何重構，只是知道些皮毛，又自我感覺良好的樣子，翻出很久都沒電的kindle，本想買本重構的書看，突然記起找了下塵封已久的《重構 改善既有代碼的設計》，再次拜讀一遍吧，希望能形成一套重構的方法論，
重構：對軟體內部結構的一種調整，目的是再不改變軟體可觀察行為的前提下，提高其可理解性，降低修改成本，
為何重構：重構改進軟體設計；重構使軟體更容易理解；重構幫助找到bug；重構提高編程速度，
何時重構：書里提到了“三次法則”：第一次做某件事時只管去做；第二次做類似的事會產生反感，但無論如何還是可以去做；第三次再做類似的事，你就應該重構，事不過三，三則重構，添加功能時重構，修補錯誤時重構，復審代碼時重構，
Duplicated Code（重復代碼）
Long Method（過長函式）
Large Class（過大的類）
Long Parameter List（過長引數列）
Divergent Change（發散式變化） 某個類因為不同的原因在不同的方向上發生變化，比如切換資料庫型別，引起了修改多個函式來適配，
Shotgun Surgery（霰彈式修改） 每遇到某種變化，需要在許多不同的類內做許多小修改，
Feature Envy（依戀情結） 函式對某個類的興趣高過了對自己所處類的興趣，最通常遇到的就是資料類，比如某個函式訪問大部分資料類的資料，
Data Clumps（資料泥團） 常常在很多地方看到相同的三四項資料，比如兩個類中相同的欄位，許多函式簽名中相同的引數，
Primitive Obsession（基本型別偏執） 如果你有一組應該總是被放在一起的欄位，那么就不要固執的使用基本型別，使用物件，
Switch Statements（switch驚悚現身） 少用switch陳述句，這個語法的問題就是重復，
Parallel Inheritance Hierarchies（平行繼承體系） 某個繼承體系的類名稱前綴和另一個繼承體系的類名稱前綴完全相同，
Lazy Class（冗贅類） 隨著時間和代碼的演進，某個類逐漸失去了存在的價值，
Speulative Generality（夸夸其談未來性） 在還不需要的時候就按照未來可能會用到，會擴展的想法來寫，比如抽象，
Temporary Field（令人迷惑的暫時欄位） 其內某個實體變數僅為某種特定情況而設，
Message Chains（過度耦合的訊息鏈） 物件1向物件2請求物件3，再向物件3請求物件4，再向物件4請求物件5，這就是訊息鏈，
Middle Man（中間人） 某個類介面有一半的函式都委托給其他類，
Inappropriate Intimacy（狎昵關系） 兩個類過于親密，過于關心彼此的private成分，
Alternative Classes with Different Interfaces（異曲同工的類） 兩個函式做同一件事，卻有著不同的簽名，
Incomplete Library Class（不完美的庫類）
Data Class（純資料類） 資料類必然會被其他類過分細瑣的操控著，
Refused Bequest（被決絕的遺贈） 子類復用了超類的實作，卻又不愿意支持超類的介面，
Comments（過多的注釋）
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/44290.html
標籤：架構設計
上一篇：SVN中怎樣忽略當前檔案不提交
下一篇：微服務的資料庫設計