# 章節十五 集成 by Kent Beck 現在，你已經擁有了七巧板的每一塊：你已經了解了重構的基礎，知道了重構的分類，還實踐了所有這些重構。同時，你已經很擅長測試了，所以你不再畏首畏尾。 于是你可能想：「我已經知道如何重構了。」不，還沒有。 前面列出的技術僅僅是一個起點，是你登堂入室之前的大門。如果沒有這些技術，你根本無法對運行中的程序進行任何設計上的改動。有了這些技術，你仍然做不到，但起碼可以開始嘗試了。 這些技術如此精彩，可它們卻僅僅是個開始，這是為什么？答案很簡單：因為你還 不知道何時應該使用它們、何時不應該使用、何時開始、何時停止、何時前進、何 時等待。使重構能夠成功的，不是前面各自獨立的技術，而是這種節奏。 當你真正懂得這一切時，你又是怎么知道的呢？當你開始冷靜下來，你就會知道，自己已經真正「得道」了。那時候你將有絕對的自信：不論別人留下的代碼多么雜 亂無章，你都可以將它變好，好到足以進行后續的開發。 不過，大多數時候，「得道」的標志是：你可以自信地停止重構。在重構者的整場表演中，「停止」正是壓軸大戲。一開始你為自己選擇一個大目標，例如「去掉一 堆不必要的subclass」。然后你開始向著這個目標前進，每一步都走得小而堅定，每一步都有備份，保證能夠回頭。好的，你離目標愈來愈近，愈來愈近，現在只剩兩個函數需要合并，然后就將大功告成。 就在此時，意想不到的事情發生了：你再也無法前進一步。也許是因為時間太晚， 你太疲倦；也許是因為一開始你的判斷就出錯，實際上不可能去掉所有subclass； 也許是因為沒有足夠的測試來支持你。總而言之，你的自信灰飛煙滅了，你無法再自信滿滿地跨出下一步。你認為自己應該沒把任何東西搞亂，但也無法確定。這是該停下來的時候了。如果代碼已經比重構之前好，那么就把它集成到系統中， 發布你的成果。如果代碼并沒有變好，就果斷放棄這些無用的工作，回到起始點。 然后，為自己學到一課而高興，為這次重構沒能成功而抱憾。那么，明天怎么辦？ 明天，或者后天，或者下個月，甚至可能明年，靈感總會來的。為了等待進行一項重構的后一半所需的靈感，我最多曾經等過九個月。你可能會明白自己錯在哪里， 也可能明白自己對在哪里，總之都能使你想清楚下一個步驟如何進行。然后，你就可以像最初一樣自信地跨出這一步。也許你羞愧地想：『我太笨了，竟然這么久都沒想到這一步。』大可不必，每個人都是這樣的。 這有點像在懸崖峭壁上的小徑行走：只要有光，你就可以前進，雖然謹慎卻仍然自信；但是一旦太陽下山，你就應該停止前進；夜晚你應該睡覺，并且相信明天早晨太陽仍舊升起。 這聽起來似乎有點神秘而模糊，近乎清談玄想。從感覺上來說，的確如此，因為這 是一種全新的編程方式。當你真正理解重構之后，系統的整個設計對你來說，就像源碼文件中的字符那樣可以隨心所欲地操控。你可以直接感受到整個設計，可以清楚看到如何將設計變得更靈活，也可以看到如何修改它：這里修改一點，于是這樣表現；那里修改一點，于是那樣表現。 但是，從另一個角度來說，這也并非那么地祌秘而模糊。重構是一種可以學習的技術，你可以從本書讀得并學習它的各個組成。然后，只要把這些技術集成在一起并使之完善，就可以從一個全新角度看待軟件開發。 正如我所說，這是一種可以學習的技術。那么，應該如何學習呢？ - 隨時挑一個目標。某個地方的代碼開始發臭了，你就應該將問題解決掉。你 應該朝目標前進，達成目標后就停止。你之所以重構，不是為了探索真善美（至少不全是〕，而是為了讓你的系統更容易被人理解，為了防止程序變得散亂。 - 沒把握就停下來。朝目標前進的過程中，可能會有這樣的時候：你無法證明自己所做的一切能夠保持程序原本的語義。此時你就應該停下來。如果代碼已經改善了一些，就發布你的成果；如果沒有，就撤銷所有修改。 - 學習原路返回。重構的原則不好學，而且很容易遺失準頭。就連我自己，也 經常忘記這些原則。我有時會連續做兩、三項甚至四項重構，而沒有每次執行測試用例（test cases）。當然那是因為我完全相信，即使沒有測試的幫助，我也不會出 錯。于是我就放手干了。然后，「砰」的一聲，某個測試失敗，我卻無法找到究竟哪一次修改造成了這個問題。 這時候你一定很愿意就地調試，試圖從麻煩中脫身。畢竟，不管怎么說，一開始所有測試都能夠正常運行，現在要讓它們再次正常運行，會困難到哪里去？停！你的重構己經失控了，如果繼續向前走，你根本不可能知道如何奪回控制權。你應該回到最近一個沒有出錯的狀態，然后逐一重復剛才做過的重構項，每次重構之后一定要運行所有測試。 站著說話不腰疼，以上一切聽起來似乎顯而易見。當你出錯的時候，使系統極大簡化的一個方案也許已經近在咫尺，這時候要你停下來回到起點，不啻是最痛苦的事情。但是，現在，趁你頭腦還清楚的時候，請想一想：如果你第一次重構用 了一小時，重復它只需十分鐘就夠了，所以如果你退回原點，十分鐘之內一定能夠再次達到現在的進度。但如果你繼續前進，調試所需時間也許是五秒種，也許是兩小時。 當然，我現在說這些，也是看人挑擔不吃力，實際做起來困難得多。我個人曾經因為沒有遵循這條建議，花了四個小時進行三次嘗試。我失控、放棄、慢慢前進、再次失控、再重復……真是痛苦的四個小時。這不是有趣的事，所以你需要幫助。 - 二重奏。和別人一起重構，可以收到更好的效果。兩人結伴，對于任何一種軟件開發都有很多好處，對于重構也不例外。重構時，小心謹慎按部就班的態度是有好處的。如果兩人結伴，你的搭檔能夠幫助你一步一步前進，你也能夠幫助他 （她）。重構時，時刻留意遠景目標是有好處的。如果兩人結伴，你的搭檔可能看到你沒看到的東西，能想到你沒想到的事情。重構時，明智結束是有好處的。如果你的搭檔不知道你在干什么，那就意味你肯定也不知道自己在干什么，此時你就應該結束重構。最重要的是，重構時，擁有絕對自信是絕對有好處的。如果兩人結伴，你的搭檔能夠給你溫柔的鼓勵，讓你不致于灰心喪氣。 與搭檔協同工作的另一方面就是交談。你必須講出你所想做的事，這樣你們兩個才能朝著同一個方向努力。你得把你正在做的事情講出來，這樣你的搭檔才有可能指出你的錯誤。你得把剛才做過的事情講出來，這樣下次遇到同樣情況時你才能做得更好。所有這些交談都有助于你更清楚了解如何讓個別的重構項適應整個重構節 奏。 即使你已經在你的重構目標（代碼〕中工作了好幾年，一絲一縷了然于胸，但只要發現其中臭味，以及消除臭味的重構手法，你就有可能看到程序的另一種可能。你也許會想立刻挽起袖子，把你看到的所有問題都解決掉。不，不要這么莽撞。沒有 一位經理愿意聽到他的開發成員說「我們要停工三個月來清理以前的代碼」。而且開發人員本來也就不應該這樣做。大規模的重構只會帶來災難。 你面前的代碼也許看起來混亂極了，不要著急，一點一點慢慢地解決這些問題。當你想要添加新功能時，用上幾分鐘時間把代碼整理一下。如果首先添加一些測試能使你對整理工作更有信心，那就那么做，它們會回報你的努力。如果在添加新代碼之前進行重構，那么添加新代碼的風險將大大降低。重構可以使你更好理解代碼的作用和工作方式，這使得新功能的添加更容易。而且重構之后代碼的質量也會大大提高，下次你再有機會處理它們的時候，肯定會對目前所做的重構感到非常滿意。 永遠不要忘記「兩頂帽子」。重構時你總會發現某些代碼并不正確。你絕對相信自己的判斷，因此想馬上把它們改正過來。啊，頂住誘惑，別那么做。重構時你的目標之一就是保持代碼的功能完全不變，既不多也不少。對于那些需要修改的東西，列個清單把它們記錄下來（通常我在計算器旁邊放一張索引卡），需要添加或修改 的測試用例（test cases）、需要進行的其他重構、需要撰寫的文檔、需要畫的圖…… 都暫時記在卡上。這樣就不會忘掉這些需要完成的工作。千萬別讓這些工作打亂你 手上的工作。重構完成之后，再去做這些事情不遲。