《重構：改善既有代碼的設計》—第2章2.3節何時重構

本節書摘來自異步社群《重構：改善既有代碼的設計》一書中的第2章，第2.3節何時重構，作者【美】martin fowler，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

2.3　何時重構

當我談論重構，常常有人問我應該怎樣安排重構時間表。我們是不是應該每兩個月就專門安排兩個星期來進行重構呢?

幾乎任何情況下我都反對專門撥出時間進行重構。在我看來，重構本來就不是一件應該特别撥出時間做的事情，重構應該随時随地進行。你不應該為重構而重構，你之是以重構，是因為你想做别的什麼事，而重構可以幫助你把那些事做好。

三次法則

don roberts給了我一條準則：第一次做某件事時隻管去做；第二次做類似的事會産生反感，但無論如何還是可以去做；第三次再做類似的事，你就應該重構。

事不過三，三則重構。

添加功能時重構

最常見的重構時機就是我想給軟體添加新特性的時候。此時，重構的直接原因往往是為了幫助我了解需要修改的代碼——這些代碼可能是别人寫的，也可能是我自己寫的。無論何時，隻要我想了解代碼所做的事，我就會問自己：是否能對這段代碼進行重構，使我能更快地了解它。然後我就會重構。之是以這麼做，部分原因是為了讓我下次再看這段代碼時容易了解，但最主要的原因是：如果在前進過程中把代碼結構理清，我就可以從中了解更多東西。

在這裡，重構的另一個原動力是：代碼的設計無法幫助我輕松添加我所需要的特性。我看着設計，然後對自己說：“如果用某種方式來設計，添加特性會簡單得多。”這種情況下我不會因為自己過去的錯誤而懊惱——我用重構來彌補它。之是以這麼做，部分原因是為了讓未來增加新特性時能夠更輕松一些，但最主要的原因還是：我發現這是最快捷的途徑。重構是一個快速流暢的過程，一旦完成重構，新特性的添加就會更快速、更流暢。　

修補錯誤時重構

調試過程中運用重構，多半是為了讓代碼更具可讀性。當我看着代碼并努力了解它的時候，我用重構幫助加深自己的了解。我發現以這種程式來處理代碼，常常能夠幫助我找出bug。你可以這麼想：如果收到一份錯誤報告，這就是需要重構的信号，因為顯然代碼還不夠清晰——沒有清晰到讓你能一眼看出bug。

複審代碼時重構

很多公司都會做正常的代碼複審，因為這種活動可以改善開發狀況。這種活動有助于在開發團隊中傳播知識，也有助于讓較有經驗的開發者把知識傳遞給比較欠缺經驗的人，并幫助更多人了解大型軟體系統中的更多部分。代碼複審對于編寫清晰代碼也很重要。我的代碼也許對我自己來說很清晰，對他人則不然。這是無法避免的，因為要讓開發者設身處地為那些不熟悉自己所做所為的人着想，實在太困難了。代碼複審也讓更多人有機會提出有用的建議，畢竟我在一個星期之内能夠想出的好點子很有限。如果能得到别人的幫助，我的生活會滋潤得多，是以我總是期待更多複審。

我發現，重構可以幫助我複審别人的代碼。開始重構前我可以先閱讀代碼，得到一定程度的了解，并提出一些建議。一旦想到一些點子，我就會考慮是否可以通過重構立即輕松地實作它們。如果可以，我就會動手。這樣做了幾次以後，我可以把代碼看得更清楚，提出更多恰當的建議。我不必想象代碼應該是什麼樣，我可以“看見”它是什麼樣。于是我可以獲得更高層次的認識。如果不進行重構，我永遠無法得到這樣的認識。

重構還可以幫助代碼複審工作得到更具體的結果。不僅獲得建議，而且其中許多建議能夠立刻實作。最終你将從實踐中得到比以往多得多的成就感。

為了讓過程正常運轉，你的複審團隊必須保持精練。就我的經驗，最好是一個複審者搭配一個原作者，共同處理這些代碼。複審者提出修改建議，然後兩人共同判斷這些修改是否能夠通過重構輕松實作。果真能夠如此，就一起着手修改。

如果是比較大的設計複審工作，那麼在一個較大團隊内保留多種觀點通常會更好一些。此時直接展示代碼往往不是最佳辦法。我喜歡運用uml示意圖展現設計，并以crc卡展示軟體情節。換句話說，我會和某個團隊進行設計複審，而和單個複審者進行代碼複審。

極限程式設計［beck，xp］中的“結對程式設計”形式，把代碼複審的積極性發揮到了極緻。一旦采用這種形式，所有正式開發任務都由兩名開發者在同一台機器上進行。這樣便在開發過程中形成随時進行的代碼複審工作，而重構也就被包含在開發過程内了。

為什麼重構有用

——kent beck

程式有兩面價值：“今天可以為你做什麼”和“明天可以為你做什麼”。大多數時候，我們都隻關注自己今天想要程式做什麼。不論是修複錯誤或是添加特性，我們都是為了讓程式能力更強，讓它在今天更有價值。

但是系統當下的行為，隻是整個故事的一部分，如果沒有認清這一點，你無法長期從事程式設計工作。如果你為求完成今天的任務而不擇手段，導緻不可能在明天完成明天的任務，那麼最終還是會失敗。但是，你知道自己今天需要什麼，卻不一定知道自己明天需要什麼。也許你可以猜到明天的需求，也許吧，但肯定還有些事情出乎你的意料。

對于今天的工作，我了解得很充分；對于明天的工作，我了解得不夠充分。但如果我純粹隻是為今天工作，明天我将完全無法工作。

重構是一條擺脫困境的道路。如果你發現昨天的決定已經不适合今天的情況，放心改變這個決定就是，然後你就可以完成今天的工作了。明天，喔，明天回頭看今天的了解也許覺得很幼稚，那時你還可以改變你的了解。

是什麼讓程式如此難以相與? 眼下我能想起下述四個原因，它們是：

難以閱讀的程式，難以修改；

邏輯重複的程式，難以修改；

添加新行為時需要修改已有代碼的程式，難以修改；

帶複雜條件邏輯的程式，難以修改。

是以，我們希望程式：(1) 容易閱讀；(2) 所有邏輯都隻在唯一地點指定；(3) 新的改動不會危及現有行為；(4) 盡可能簡單表達條件邏輯。

重構是這樣一個過程：它在一個目前可運作的程式上進行，在不改變程式行為的前提下使其具備上述美好性質，使我們能夠繼續保持高速開發，進而增加程式的價值。