再寫重構是在CSDN上看到了一篇關於重構軟件並不會改善代碼質量的文章。一笑了之之後，還想再談談個人對重構的看法。
![]()
在我的職業生涯中，有很多重構的經歷，最後也都得到了很好的效果，因此，本人謹以自己的經歷爲例，從重構的法與度兩個方面進行一些總結。至於重構的作用與學習思路，可以參見我4年前的兩篇文章《在代碼重構中蛻變》《再談對“重構”的學習》。
本文主要談重構的方法，另成一文談重構的度量。
方法，爲達到目的而採取的方式、手段、行爲方式。
提到方法，必須得說，Martin Fowler著的《重構，改善既有代碼的設計》是必讀的經典。正是這本書，把重構的概念廣而傳播，讓我們認識了什麼是重構以及重構的數十種基本方法。那麼問題來了，既然大師已經把方法都寫得如此清晰了，我們又談什麼方法呢？我們要談的是重構在敏捷開發過程中的組織與實施。
現在很多團隊都在用敏捷開發，不停的迭代着，如何在這樣的開發模型中進行重構，這是我們接下來要探討的問題。
爲了把這個問題說清楚，我們還要對重構的概念細分爲兩個層次。一個層次是以代碼和模塊爲對象的小範圍重構，我們估且稱之爲代碼重構；另一個層次是以更大範圍的架構爲對象的重構，下文我們稱之爲架構重構。
先來看代碼重構。代碼重構其實與迭代的關係不大，我更喜歡把代碼重構與工程師的個人能力與素養結合在一起。優秀的工程師，骨子裏頭流淌的都是代碼。只要看到代碼，就能敏感的聞到那些“壞味道”，就爲此坐立不安，就自然而然的要把這些“壞味道”消滅。他們隨手改一些意義不明確的類名、方法名、變量名，重新調整類的職責分配，複雜代碼進行函數提取，用小函數替換長的表達式或複雜的邏輯運算……，任何一個小的修改，都讓代碼的可讀性趨向更好，這就是方法。無論是否採用敏捷模型，這種代碼重構都應該隨時發生。不需要進行方法指導，只需要培養這種意識就好。要知道，勿以善小而不爲，溪流可以成江海，勿以惡小而爲之，蟻穴可以潰壩堤。正是這樣隨手而爲，代碼就能保持在較好的水平，而任何的小混亂，都可能讓代碼走向深淵。一句話，對代碼質量的高標準嚴要求就是方，團隊中所有的人都是同一標準，代碼重構就會發生於無形。當然，這樣的重構也並不能100%的改善代碼質量，並不是見到所有的switch case語句都用子類化處理就是恰當的，質量改善與否與重構本身無關，而是與進行重構的人有關。
再來看架構重構。一涉及到架構，自然而然的就會發生在對項目有重大影響的問題上了。對於敏捷模型，由於其強調的是少預先架構，擁抱變化，所以都或多或少的存在架構重構。比如項目早期採用了按功能劃分模塊的做法快速上線了功能，但隨着功能增多，出現了公共部分，爲了減少重複勞動，會引入層次結構。這樣的變化，往往需要時間、人員的資源投入，會爲發版速度帶來影響，所以實踐起來相對會困難得多。還有些時候是爲了性能優化進行架構調整，這個的目標是性能優化而不是架構調整，只是架構影響了性能而已，不可混爲一談。
架構重構要想執行得好，需要關注以下幾個要素。
一是目標清晰，架構方案明確。要重構什麼，重構成什麼樣子，會帶來什麼好處，會引入什麼風險，大約需要多少資源……。只有目標清晰，才能進行決策。看到過一些用重構提高性能，用重構鍛鍊隊伍的例子，最後不僅結構沒好轉，反而走向進一步的混亂，最終進行演變成重寫。如果是進行架構重構，就要把這種目標確定下來，充分評估必要性、可行性，明確結果。比如在我的一項重構中，爲了支持更多功能的加入，減少公共部分的重複，將縱向結構重構爲橫向結構，然後設計好新的架構並在團隊當中達成共識。
二是方案一致性。軟件開發是複雜的，架構關係到參與的每一個人，架構師一定要讓方案得到共識，形成一致性的理解，否則在實施過程中會發生偏離，增加成本和風險。給團隊成員講清楚吧，真的不是每個人都能理解。
三是合理計劃。架構重構往往會跨迭代進行，在少影響版本發佈節奏的前提下進行，這就要把重構計劃按挫代分解，合理規劃，控制節奏。比如我們的每個迭代都要有版本上線，這樣就必須得跨迭代重構，不僅要分解，還要能與迭代中正常的功能開發結合到一起，是需要與產品團隊、開發團隊、測試團隊共同規劃的。架構重構是個長期的多輪的過程，要注意何時啓動一輪，何時停止。
四是架構師參與。架構師不是畫圖用的，在架構重構中，必須參與代碼，即使不親自寫代碼，也要每天關注代碼的實現，防止與架構設計出現較大差異。這是能夠按預期方案實現的關鍵。
總結一下，對於代碼重構，要用代碼質量爲標準，作爲日常的一種編碼方法和習慣加以強化。對於架構重構，要以架構師爲主導，慎思篤行。
