### 使用工具進行重構 和手工重構相比，自動化工具所支持的重構，給人一種完全不同的感覺。即使有測試套件（test suite）織成的安全網，手工重構仍然是很耗時的工作。正是這個簡單的事實造成很多程序員不愿進行重構，盡管他們知道自己應該重構，但畢竟重構的成本太大了。如果能夠把重構變得像調整代碼格式那么簡單，程序員自然也會樂意像整理代碼外觀那樣去整理系統的設計。而這樣的整理對代碼的可維護性、可復用性和可理解性，都能夠帶來深遠的正面影響。Kent Back 如是說； Kent Back Refactoring Browser 將會完全改變你的編程思路。以前你可能會想：『呃，我應該修改這個名字，但……』，現在，所有這些讓你煩心的事情都煙消云散了，因為[Refactoring Browser]里頭有個菜單選項（menu item ）就是專門用來易名的，你只管放心用它就是了。 剛開始使用這個工具時，我按照以前的節奏，走了大概兩個小時：我打算進行一項重構，于是抬頭望著天空五分鐘，然后手工完成重構，然后再一次抬頭望天。很快我發現：我必須學會以更大的范圍、更快的節奏來考慮重構。現在，開發過程中我大約以一半時間進行重構，另一半時間輸入新代碼，兩者的進行速度幾乎完全相同。 由于有了這種級別的工具支持，重構和編程之間的差異愈來愈小了。我們幾乎不會再說『我正在編程』或『我正在重構』，我們說得更多的是『把這個函數的這一部分提煉出來，把它推到superclass 去，然后添加一行語句，調用新subclass 中的新函數——我正在開發的那個函數。』由于自動化重構之后無須測試，因此編程與重構之間的差異、「更換帽子」的過程等等盡管仍然存在，但都遠不如以前那樣明顯了。 以Extract Method 這一重要的重構手法為例。如果你要手工進行此一重構， 需要檢查的東西相當多。如果使用Refactoring Browser，你只需簡單地圈選出你要提煉的段落，然后點選菜單選項（menu item ）"Extract Method"就行了。Refactoring Browser 會自動檢查被圈選的代碼段落是否可以提煉。代碼無法提煉的原因可能有以下幾點：它可能只包含部分標識符聲明，或者可能對某個變量賦值而該變量又被其他代碼用到。所有這些情況，你都完全不必擔心，因為重構工具會幫助你處理這一切。然后，Refactoring Browser 會計算出新函數所需的參數，并要求你為新函數取一個名稱。你還可以決定新函數參數的排列順序。所有的準備工作都做完以后，Refactoring Browser 會把你圈選的代碼從源函數中提煉出來，并在源函數中加上對新函數的調用。隨后它會在源函數所屬的class 中建立新函數，并以用戶指定的名稱為新函數命名。整個過程只需15秒種。你可以拿這個時間長短和手工執行Extract Method 各步驟所需時間做個比較，看看自動化重構工具的威力。 隨著重構成本的降低，設計錯誤也不再像從前那樣帶來昂貴代價了。由于彌補設計錯誤所需的成本降低了，需要預先做的設計也就更少了。預先設計是一項帶有預測性質的工作，因為項目激活之時，需求往往還不明朗。由于設計時尚未編寫代碼，所以正確的設計方式應該是：盡量簡化「需求尚未明朗」的那一部分代碼。過去，無論最初的設計方案水平如何，我們都不得不忍受，因為修改設計的代價實在太高了。有了自動化重構工具的幫助，我們可以讓設計更具可變性，因為修改設計不再需要付出那么高的代價了。如今，我們可以只對當前完全了解的問題進行設計，因為我們知道以后可以很方便地擴展設計方案以加入額外的靈活性。我們不再需要預測系統未來所有可能的修改。如果發現當前的設計給編程帶來麻煩，造成第3章所說的臭味，我們可以很快修改設計，使代碼更干凈、更可維護。 工具輔助下的重構工作，也影響了測試。擁有自動化重構工具的輔助之后，所需測試少多了，因為很多重構都可以自動進行，無需再做測試。當然，總有一些重構是無法自動進行的，因此測試步驟永遠都不可能被完全忽略。經驗顯示：在自動化重構工具的協助下，我們每天所需運行的測試數量，和在「無自動化重構工具」環境中大致相當，但完成的重構數量則大大增加。 正如Martin 指出，Java 也需要這樣的自動化重構工具。以下我們將提出一些準則——只有滿足這些準則的自動化重構工具，才是成功的工具。盡管也提到了技術方面的準則，但我們相信，實用性方面的準則更重要得多。