### 何時重構 當我談論重構，常常有人問我應該怎樣安排重構時間表。我們是不是應該每兩個月 就專門安排兩個星期來進行重構呢？ 幾乎任何情況下我都反對專門撥出時問進行重構。在我看來，重構本來就不是一件「特別撥出時間做」的事情，重構應該隨時隨地進行。你不應該為重構而重構，你之所以重構，是因為你想做別的什么事，而重構可以幫助你把那些事做好。 **三次法則〔The Rule of Three〕** Don Roberts給了我一條準則：第一次做某件事時只管去做；第二次做類似的事會產生反感，但無論如何還是做了；第三次再做類似的事，你就應該重構。 Tip: 事不過三，三則重構（Three strikes and you refactor） **添加功能時一并重構** 最常見的重構時機就是我想給軟件添加新特性的時候。此時，重構的第一個原因往往是為了幫助我理解需要修改的代碼。這些代碼可能是別人寫的，也可能是我自己寫的。無論何時只要我想理解代碼所做的事，我就會問自己：是否能對這段代碼進行重構，使我能更快理解它。然后我就會重構。之所以這么做，部分原因是為了讓我下次再看這段代碼時容易理解，但最主耍的原因是：如果在前進過程中把代碼結構理清，我就可以從中理解更多東西。 在這里，重構的另一個原動力是：代碼的設計無法幫助我輕松添加我所需要的特性。我看著設計，然后對自己說：「如果用某種方式來設計，添加特性會簡單得多」。這種情況下我不會因為自己過去的錯誤而懊惱——我用重構來彌補它。之所以這么做，部分原因是為了讓未來增加新特性時能夠更輕松一些，但最主要的原因還是：我發現這是最快捷的途徑。重構是一個快速流暢的過程，一旦完成重構，新特性的添加就會更快速、更流暢。 **修補錯誤吋一并重構** 調試過程中運用重構，多半是為了讓代碼更具可讀性。當我看著代碼并努力理解它的時候，我用重構幫助改善自己的理解。我發現以這種程序來處理代碼，常常能夠幫助我找出臭蟲。你可以這么想：如果收到一份錯誤報告，這就是需要重構的信號，因為顯然代碼還不夠清晰一不夠清晰到讓你一目了然發現臭蟲。 **復審代碼吋一并重構** 很多公司都會做常態性的代碼復審工作（code reviews），因為這種活動可以改善開發狀況。這種活動有助于在幵發團隊中傳播知識，也有助于讓較有經驗的開發者把知識傳遞給比較欠缺經驗的人，并幫助更多人理解大型軟件系統中的更多部分。代碼復審工作對于編寫清晰代碼也很重要。我的代碼也許對我自己來說很清晰，對他人則不然。這是無法避免的，因為要讓幵發者設身處地為那些不熟悉自己所做所為的人設想，實在太困難了。代碼復審也讓更多人有機會提出有用的建議，畢竟我在一個星期之內能夠想出的好點子很有限。如果能得到別人的幫助，我的生活會舒服得多，所以我總是期待更多復審。 我發現，重構可以幫助我復審別人的代碼。開始重構前我可以先閱讀代碼，得到一定程度的理解，并提出一些建議。一旦想到一些點子，我就會考慮是否可以通過重構立即輕松地實現它們。如果可以，我就會動手。這樣做了幾次以后，我可以把代碼看得更清楚，提出更多恰當的建議。我不必想像代碼「應該是什么樣」，我可以「看見」它是什么樣。于是我可以獲得更髙層次的認識。如果不進行重構，我永遠無法得到這樣的認識。 重構還可以幫助代碼復審工作得到更具體的結果。不僅獲得建議，而且其中許多建議能夠立刻實現。最終你將從實踐中得到比以往多得多的成就感。 為了讓過程正常運轉，你的復審團隊必須保持精練。就我的經驗，最好是一個復審者搭配一個原作者，共同處理這些代碼。復審者提出修改建議，然后兩人共同判斷這些修改是否能夠通過重構輕松實現。果真能夠如此，就一起著手修改。 如果是比較大的設計復審工作，那么，在一個較大團隊內保留多種觀點通常會更好一些。此時直接展示代碼往往不是最佳辦法。我喜歡運用示意圖展現設計，并以CRC卡展示軟件情節。換句話說，我會和某個團隊進行設計復審，而和個別 (單一〉復審者進行代碼復審。 極限編程（Extreme Programming）[Beck, XP]中的「搭檔（成對〉編程」（Pair Programming）形式，把代碼復審的積極性發揮到了極致。一旦采用這種形式，所有正式開發任務都由兩名開發者在同一臺機器上進行。這樣便在開發過程中形成隨時進行的代碼復審工作，而重構也就被包含在幵發過程內了。 **為什么重構有用（Why Refactoring Works）** —— Kent Beck 程序有兩面價值：「今天可以為你做什么」和「明天可以為你做什么」。大多數時候，我們都只關注自己今天想要程序做什么。不論是修復錯誤或是添加特性，我們都是為了讓程序力更強，讓它在今天更有價值。 但是系統當下行為，只是整個故事的一部分，如果沒有認清這一點，你無法長期從事編程工作。如果你「為求完成今天任務」而釆取的手法使你不可能在明天完成明天的任務，那么你還是失敗。但是，你知道自己今天需要什么，卻不一定知道自己明天需要什么。也許你可以猜到明天的需求，也許吧，但肯定還有些事情出乎你的意料。 對于今天的工作，我了解得很充分：對于明天的工作，我了解得不夠充分。但如果我純粹只是為今天工作，明天我將完全無法工作。 重構是一條擺脫束縛的道路。如果你發現昨天的決定已經不適合今天的情況，放心改變這個決定就是，然后你就可以完成今天的工作了。明天，喔，明天回頭看今天的理解也許決定幼稚，那是你還可以改變你的理解。 是什么讓程序如此難以相與？下筆此刻，我想起四個原因，它們是： - 難以閱讀的程序，難以修改。 - 邏輯復雜（duplicated logic）的程序，難以修改。 - 添加新行為時需要修改既有代碼者，難以修改。 - 帶復雜條件邏輯（complex conditional logic）的程序，難以修改。 因此，我們希望程序：（1）容易理解；（2）所有邏輯都只在唯一地點指定；（3）新的改動不會危及現有行為；（4）盡可能簡單表達條件邏輯（conditional logic）。 重構是這樣一個過程：它在一個目前可運行的程序上進行，企圖在「不改變程序行為」的情況下賦予上述美好性質，使我們能夠繼續保持高速開發，從而增加程序的價值。