再談對“重構”的學習

        數月前，我曾經寫過一篇博文《在代碼重構中蛻變》，文中提到了我對重構的一些認識，今天再談重構，緣起於近期針對重構進行了6次技術分享，每次對應《重構——改善既有代碼的設計》一書中的一章內容，在此過程中與團隊一起再學習了一次重構，因此，這次再談重構，就從學習的角度說起。

        當再次拿起這本書時，想到的就是第一次閱讀時的體會。幾年前，第一次開啟書，讀完了第六章——重新組織你的函數，知道了大體上重構是怎麼回事，如何完成，然後就再也讀不下去了。當時心裡想，雖然書裡列出了若干條重構手法，但看上去好像千篇一律了，像提煉函數、將函數內聯、將臨時變數內聯……實在是太簡單了，只要我想改，隨手就把代碼改了，還要這些手法幹嘛呢？這就是我當時的實際想法，由此，我就學完了重構，書也束之高閣了。

        再學重構時，我認識到了很多當時的局限。

        首先，重構手法只是便於表達和記錄，不是要死記硬背的東西，更不是放之四海而皆準的數理化公式定理。我們要學的不是每一條手法的名稱、動機、作法，而是要深刻領會每一條手法背後所適用的場合。我們可以一個名稱都記不住，但我們要形成用這種思路提升代碼可讀性的認識。

        其次，重構本身是一種理念。學習重構，就是要學習從能識別出代碼中的壞味道，到能消除代碼中的壞味道的思維過程，就是要形成這樣的意識，並且能在實際工作當中加以實踐運用，就是要想方設法的讓代碼清爽。一些必要的手法可以開拓我們改進代碼的思路，但並不是只有這種方法才行。

        再次，重構還是一種決策過程。程式是平衡的，不僅架構師在面對各種決策，所有工程師其實都要面對，要在各種約束中做出選擇。重構也是如此，我們看到很多的重構手法是互相矛盾的，比如‘將單向關聯改為雙向’對應的就是‘將雙向關聯改為單向’，比如‘提煉子類’與‘提煉超類’等等，具體用哪種更合適，那是需要我們在實際情況中去決策的。

        最後，重構從更廣泛的意義上來講，裡面除了有修改代碼的方法以外，更包含了編程標準或規範，以及程式設計思維。裡面的很多手法就是設計模式，所以學習重構，就不能只把它當成一個修改代碼的手段來學了。

        很顯然，重構對於提高代碼品質，提高編碼能力是非常重要的，那麼怎樣才能快速的掌握這一工程師必備技能呢？一句話，在明白重構本質的前提下去實踐。

        看書無疑還是枯燥的，只有把它轉化成實際應用，才能加深認識。如果手中有實際的代碼，不妨從自己能把握的小範圍開始，重新命名、提煉、內聯、搬移……看看改完了是否讓別人能更容易理解。如果手中沒有實際代碼，可喜的是書中的範例很不錯，要在IDE中嘗試著來做一下。但要注意三點：一是要頻繁測試，尤其是產品代碼，一定不能改變現有的功能，不能引入新的bug；二是只在自己能控制的範圍內修改，不要修改其他人的代碼甚至整體結構，謹慎；三是書中的代碼是示意性的，很多是編譯通不過的，要自己親自動手才能領會其中的細節。

        我想，對重構有了正確的認識，再加上勤於實踐，把思路著重於重構手法的應用情境而不是作法細節甚至對手法名稱的背誦，就一定能夠用最短的時間掌握這種技能了。

——歡迎轉載，請註明出處 http://blog.csdn.net/caowenbin ——