重構的七宗罪

重構經過了十幾年的發展和應用，可以說它是極限編程中程序員最愛的實踐之一了，紛紛爭相在項目里應用。重構工作坊、Codekata重構練習等各種提升能力的方式也屢見不鮮，幫助程序員們去追求優秀的代碼和設計。然這仍然擺脫不了人們對它的各種抱怨：“搞什么，又重構”，“重構出defect來了”，“項目緊，最近不要再重構了”，“重構到什么時候停呀”。小菜也這樣被項目中的人抱怨著，覺得很委屈，找到了大牛小明。

小菜：有一大段代碼不合我意，寫的很爛。我就想最近剛好新學了點技巧，看了下模式，趕緊大干一場。沒想到做著做著組里都反對。

小明：那你有什么目標？重構想達到什么效果？

小菜：目標？啥意思？

小明：我們做事情得有目標，重構任務也是一樣的。

小菜：我不太清楚，我就是想把這段代碼改了，我刪了好多代碼，測試好多都紅了。項目好像下周發布，項目經理小東也問我什么時候完工；測試小花還說我前兩天做的功能有問題，問我是不是又重構了；

小明：你呀，今天來對了。這兩天我也在琢磨這個戲，重構七宗罪，正好給你來講一下。

1.不懂重構，為了重構而重構

“沒有目標而生活，恰如沒有羅盤而航行?！?/p>

做事情得有一個目標，拿出租車舉例：“師傅，我要去機場”。出租車師傅很清楚我們的目的地。然如果我們說，“師傅，我就是來坐車的，你隨便開吧”，就是再有經驗的司機也沒辦法把你送到終點。重構也是一樣，它需要能夠解決一定的問題，要有一個目標的引領，否則黑咕隆咚做了半天也不知道自己做了啥，最后不得不全部回滾，白費工夫。

那么重構是什么，它解決什么問題呢？

所謂重構是對軟件內部代碼及其結構的調整，期望改善代碼質量，促使程序設計架構更趨合理。說白了，重構解決的就是代碼和代碼結構的問題，它開始自壞味道，其目標就是要消除壞味道，消除那些“不合我意”的因素，讓代碼的意圖更清晰。

Martin在《重構》一書中提到了22個常見的代碼壞味道，都可以作為我們重構的目標，來指引我們的重構。如：

消除同一類兩個方法之間的重復代碼

消除某一類中的長方法

重命名

刪除A類中的死代碼

簡化復雜的條件語句

同時，重構的范圍也應是那段壞味道的代碼，在重構過程中對其，也僅對其進行修改。

小菜：我明白了。這一段代碼其實我就是想先去除重復問題的，結果改著改著就改到別的地方了。

2.不知道什么時候完工

經理，我先改上50塊錢的，你看行不行？

重構是整理代碼保持輕裝前行的重要手段，然而我們也需要能夠明確知道重構要做什么，最終的產出如何驗證?？偛荒軐椖拷浝碚f，我先改上50塊錢的？

上文提到了消除復雜條件語句是這次重構的目標，那么簡化22行-32行復雜的條件語句就是一個更具體的重構目標。有了這樣一個具體清晰的目標，“重構什么時候?！币簿褪且粋€很容易回答的問題了，不用擔心項目經理天天問你啥時候完工了。

圖片

重構其實不僅有代碼級別的重構，還包括模塊級別的重構、架構級別的重構。不同級別的復雜度不同，消除的壞味道不同，需要的時間也不同。一般來講代碼級別的重構可以在小時和天以內，架構級別需要的時間會更長一些，比如幾周或幾月或幾年。

3.沒有方法，暴力重構

“非常的建設需要非常的破壞?！?/p>

很多人都認同這一觀點。但對遺留的應用軟件、構筑過半的項目卻容不得推倒重來。以我觀察，在開始重構時僅憑自己對代碼的理解就進行剪切、復制、刪除、添加等大刀闊斧修改的人不在少數，尤其還沒有完全掌握重構手法的新人們。結果當然錯誤百出，導致測試“獎賞”一片紅。修復這些錯誤代碼少則幾個小時，多則幾天，這不是重構，這是重寫。

小菜：那怎么破呢？

無他，苦練而已。

重構是一種經千錘百煉形成的有條不紊的程序整理方法。在《重構》一書中Martin明確提出了68個代碼級別的重構手法，這些手法都是等價的。在重構的過程中即使錯了也沒關系，都可以安全回退，重新開始。其中比較常用的手法就是橋接，如當我們要刪除一個方法的時候，會新添加一個方法，然后將它的引用逐一的遷移過去，直到舊方法成為孤島，就可以將它刪除了。它能保證重構前與重構后的程序代碼功能完全一致，從而實現安全重構。

所以小菜啊，這是20個招式，回去加緊練習??；三月后再來見我。

小菜：是不是就像拳擊比賽，不能空有一身蠻力，也得有技巧。

小明：孺子可教也。

4.沒有策略，追求完美主義

重構過程中，經常出現為了消除一個壞味道，改了A類的方法，又改了B類的變量，不得不改了C類；最后發現這三者之間還有依賴，導致進行不下去了，波及面越來越廣，時間越來越長，項目經理在催，最后不得不放棄所有的代碼。

老子說：“治大國，如烹小鮮?！?/p>

調整一個正在運行中的系統也如治國，不要期望一次性調整到漂亮的代碼或架構，而是要遵循“小步前進”的方法。從問題著手，每次重構一小步。針對一個問題有目的修改，修改完后測試，測試通過后提交代碼，再進入下一輪重構。如果在改動過程中發現了其他需要修改的地方，不要順便重構，你可以把它記下來，作為下一輪重構的內容。

這種做法在代碼和模塊層面都是相對比較容易實踐，而針對架構層次的調整就相對比較復雜。這也是很多架構師需要去思考的問題，如何漸進式重構。不搞一下子半年一年的重構，而是以周以月為單位，快速的迭代，能夠很快的驗證結果獲得收益。

5.不知道結果對不對

對于簡單的代碼級別重構如果做得好是可以不用驗證結果的，然對于模塊級別或架構級別的重構，是需要的。在我遇到的多次重構架構失敗的例子中，很多是因為越做越發現很難驗證結果的正確性，越做越不知道改的對不對，最后發現很難回答老板和客戶的問題不得不失敗。

這個時候一個可以衡量重構的指標就體現它的價值：能時刻檢驗我們的成果，確認我們的重構還在解決當初的問題。目前常見的量化指標有如下四類，可供參考。

數量：代碼的行數

質量：代碼復雜度、重復讀、縮進等級、架構依賴復雜度等

時間：花費的天數

成本：投資回報率

同時也可以借助于Sonar、Structure101這樣的一些成熟工具度量和管理這些結果。

6.只談招式，不談心法

《重構》是Martin和Kent對他們多年以來整理代碼的實踐的總結，然這背后體現的是他們對軟件技術的深層次思考和經驗。很多新人執著于學習重構手法而疏于學習背后的心法，有些可惜。

Robert C Martin的《代碼整潔之道》和《敏捷軟件開發：原則、模式與實踐》、《設計模式》、Eric的《領域驅動設計：軟件核心復雜性應對之道》、《架構之美》等都是幫助大家修煉心法的不錯選擇，他們可以讓你更深層的了解代碼，更高層面看待系統，鍛煉你的嗅覺，提升你的代碼能力。

7.不了解上下文，不與團隊溝通

我們不得不承認對代碼的重構是有風險的，尤其是模塊或架構級別。這段代碼的業務是什么，為什么當時這么設計，測試覆蓋率是多少，如果這樣改會不會影響到其他模塊？對其他角色有什么影響？這些問題都要逐一回答。在風險相對較大的改動更要如此，需要和團隊成員，各個角色，包括項目經理和客戶進行溝通，談論這次重構的好處和風險，獲得足夠的評估，從而能夠做出合適的重構決策，將風險降到最低。

今天就聊這些吧。不過小菜啊，你不要擔心，重構和做其他事情一樣，要有目標有方法有策略有結果。我們在進行的時候需要以終為始，不忘本心。最重要的是要提升技術能力，學習安全重構手法，小步前進，漸進式的重構，不斷驗證重構的收益，才能迎接一個一個的重構任務，真正的成為清理代碼的高手。

加油吧，我看好你哦。

本文轉載自異步社區

安全

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。