我想讓你先了解重構，而後深刻重構

本文屬於原創文章，轉載請註明--來自桃源小盼聊技術

代碼不可能在第一次就寫得完美，這是一個持續修改的過程，那麼應該怎麼來進行呢？ 如下內容來自《重構-改善既有代碼的設計》

是什麼

• 好代碼的檢驗標準就是人們是否能垂手可得地修改它。
• 因爲預先作出良好的設計很是困難，想要既體面又快速地開發功能，重構必不可少。
• 重構的意義就在於：你永遠沒必要說對不起，只要把出問題的地方修補好就好了。
• 重構過程的精髓所在：小步修改，每次修改後就運行測試。
• 重構的最佳時機就在添加新功能以前。
• 我不專門安排一段時間來重構，而是在添加功能或修復bug的同時順便重構。
• 與其猜想將來須要哪些靈活性，須要什麼機制來提供靈活性，我更願意只根據當前的需求來構造軟件。

作什麼

• 數據結構纔是一個健壯程序的根基。
• 消除重複。
• 函數是咱們將程序拆分紅小塊的主要方式。
• 根據一個函數的意圖（作什麼）來對它命名。
• 只要更名可以提高代碼的可讀性，那就應該堅決果斷去作。
• 若是某些數據和某些函數老是一塊兒出現，某些數據常常同時變化甚至彼此相依，這就表示你應該將它們分離出去(好比提煉類)。
• 一個好的模塊化的設計，"封裝"是最關鍵的特徵之一。"封裝"意味着每一個模塊都應該儘量少了解系統的其餘部分。
• 儘可能遵循命令與查詢分離原則。
• 大部分條件邏輯只用到了基本的條件語句，但若是發現複雜條件邏輯，多態是改善這種狀況的有力工具。
• 合理的繼承關係是在程序演化的過程當中才浮現出來的：我發現了一些共同元素，但願把它們抽取到一處，因而就有了繼承關係。

注意什麼

• 數據被使用得越廣，就越是值得花精力給它一個體面的封裝。
• 若是可訪問範圍變大，重構的難度就會隨之增大，這也是說全局數據是大麻煩的緣由。
• 將一個值用於多個不一樣的用途，這就是催生混亂和bug的溫牀。
• 若是你不知道該作什麼，這纔是註釋的良好運用時機。
• 重構過程的性能問題：大多數狀況下能夠忽略它，若是有性能損耗，先完成重構，再作性能優化。
• 若是重寫比重構還容易，就別重構了。

一直在追問本身要不要總結一篇這樣偏理論性的文章。其實大部頭的書不太容易靜下心來讀，那麼我就把一些基本的知識曬出來，讓看到的人產生思考，而後能去讀原書。就算不讀這本421頁的《重構》也能對重構有一個基本的瞭解，方便在往後遇到問題時，知道去哪裏尋找答案。

原書總結了經常使用的上百種重構手法，若是真正理解了什麼是重構，本身也能夠創造一些手法，實際的業務場景纔是重構的最好戰場。