什麼是重構？
“重構”一詞想必大家耳熟能詳，就是整理程式碼唄，可事實上並不是這樣的。重構旨在不改變呼叫者行為的前提下，對內部邏輯進行調整優化，從而提高其理解性，降低其修改成本。
何時重構？
重構並不是單獨抽出時間集中處理的，而是當你想要做某個功能時，應該隨手把需要重構的地方重構了。
怎麼重構？
抽象重複邏輯
重複程式碼是最核心常見的預警資訊，如果有兩個或兩個以上的重複邏輯的程式碼，就應該考慮將其合併。例如，同一類或不同類中的方法如果存在邏輯相同的部分，就應該把相同部分抽象為獨立的方法或類。
分解長方法
當很多人閱讀別人數百行甚至上千行的程式碼後，讓人懷疑人生。為方便理解，最好的方式是把長方法分解為若干小方法，搭配上易理解的方法名，便可以像自然語言一樣理解程式碼。
減少引數
有一種習慣非常不好，就是把所有要用到的變數當做方法的引數，這樣會加劇程式碼的理解難度，對內容的擴充極其困難，當需要更多資料時，不得不修改所有方法的引數，牽一髮動全身。如果把物件作為引數，把需要用到的資料都放進物件裡，就可以有效解決引數過長的問題。
方法出軌
你要是發現一個方法頻繁的呼叫某一個類，它很可能給你戴了綠帽子，不如忍痛割愛，放其自由吧，把方法歸併到它喜歡的類，也許他們在一起生活更為合適，你一定會找到一個適合的人。
抽取變化
如果新加入一個業務型別（例如支付渠道、資料庫型別等）時，需要改動很多地方才能實現，這就意味著還有改進的空間，可以將引起變化的原因抽出來做為配置，並將變化的方法放置到一個類中，這樣不僅可以做到修改一處就應對變化，還可以很清晰的知道方法會受到影響。
組合工具類
一款語言包含很多基本型別與內建方法，但不能滿足所有需求，比如金額單位轉換、時間陣列格式轉換、UUID生成等簡單又容易忽略的小功能，如果這些功能出現的頻率很高，規則改變會帶來一連串的修改，這時可以考慮將這些小功能抽象為工具方法，並將這些方法組合為工具類。
意淫的功能
有些邏輯以為將來會有一些變化，於是安插了很多鉤子方法應對非必要的特殊情況，這樣往往提高了系統複雜性和理解成本，如果安插的鉤子都能被用到且有價值，那麼就使用，否則還是不要放在程式碼裡阻礙視線了。
減少switch
假如現在要做一個支援微信、支付寶、招行等渠道的支付平臺，需要對接不同渠道，因為不同渠道對接方式不同，就需要用switch來根據型別選擇對應渠道的對接方式，但是很多地方都可能用到這個switch，一旦新渠道加入就要滿世界的找哪裡用到了switch。
可以將switch語句移植為獨立的方法，將這些方法組成基類，case語句呼叫子類對應的方法，具體實現讓子類去完成，這樣支付渠道的增加和變更只需要修改一個類即可。
去掉無用類
建立的每一個類，對於其他人來講都是有理解成本的，如果曾經為某個變化所新增的類，在實際場景中並沒有發生變化，那麼就把這個類去掉吧，我們需要真正有價值、理解成本低的系統。
一個類會設定一些為特殊情況設定的變數，這些變數不一定都會被使用，經手你程式碼的人還要猜測當時設定這些變數的目的，非常讓人頭大，不如把這些變數和相關方法單獨放在一個類中，遮蔽具體細節，需要的功能通過方法來表達，會使功能擴充套件更高效。
去掉“幽靈類”
專案中偶爾會出現一些“幽靈類”，這些類沒有做什麼實際工作，只是負責呼叫其它的類，不如把這個“中間人”去掉，讓實際要呼叫的那個類與呼叫者發生關係。
抽象相同類為基類
如果兩個類，其中某幾個方法作用相同，名稱不同，那就可以通過修改名稱或移植方法的方式將兩個相似的類保持一致，然後把兩個類抽象出基類，以便擴充套件。
增加註釋
註釋多並不是一件壞事，它是重構的領路人，當你感覺需要為某段程式碼寫上註釋時，這意味著你認為這段程式碼不容易被他人理解，也側面證明了這就是重構發出的預警訊號，所以當想要寫註釋時，就先重構，爭取讓註釋都變得多餘。