### 重構工具的技術標準（Technical Criteria ） 重構工具最主要的用途就是讓程序員可以不必重新測試，便能對代碼進行重構。即使有了自動化測試工具，測試仍然是很費時間的，如果能完全避免測試，將可極大加快重構過程。本小節簡短討論重構工具的技術標準。惟有滿足這些標準，重構工 具才能在「保持程序行為」的前提下，對程序進行改造。 **程序數據庫（Program Database）** 對于重構工具，最早被人們所認識的需求就是「貫穿整個程序，搜索各種程序元素」的能力。例如，對于某個特定函數，找出其所有可能被調用點；對于某個特定的instance 變量（譯注：non-static 變量），找到讀/寫該變量的所有函數。在Smalltalk 這樣緊密集成的環境中，這類信息總是被維護為一種便于搜索的格式。這不是傳統意義上的數據庫，但的確是一個可搜索的數據庫。程序員只需執行一次搜索動作，就可以找到任何程序元索的交叉引用（cross references）。這種能力主要源自代碼的動態編譯機制：當任何一個class 被修改，就立刻被編譯為bytescodes，而上述的「數據庫」則同時得到更新。在較為靜態的開發環境如Java 中，程序員是把代碼輸入到文本文件中；這種環境下如果要更新程序數據庫，就必須運行一個程序來處理這些文本文件，從中提煉相關信息。這樣的更新過程和Java 代碼自身的編譯過程很相似。一些比較先進'的開發環境（例如IBM VisualAge for Java）則模仿了Smalltalk 的程序數據庫動態更新機制。 有一種原始（粗糙）的作法是：以諸如grep 之類的文本處理工具來進行搜索。這種 辦法很快就歸于失敗，因為它無法區分名為foo 的變量和名為foo 的函數。要建立程序數據庫，就必須借助語義分祈來判斷程序中每個語匯單元（token）在語句中的地位。而且這種分析在定義和函數定義兩層面上都不可少：在class 定義層面 上，需要以語義分析（semantic ana）來區分instance 變量和函數；在函數定義層面上，需要以語義分析來區分instance 變量和函數引用（method references）。 **解析樹（Parse Trees）** 絕大多數重構都必須處理函數層面下的一部分系統，通常是對「被修改之程序元素」的引用。舉個例子，如果某個instance 變量被改名，那么該class 及其subclass 對于該instance 變量的所有引用都必須更新。有些重構手法則整個運作于函數層面 下，例如將某個函數的一部分提煉為一個獨立函數。由于對函數的任何修改都必須能夠處理函數結構，因此我們需要parse trees（解析樹）的幫助。這是一種數據結構，可用以表現函數的內部結構。下面是個簡單例子： public void hello( ){ System.out.println("Hello World"); } 這個函數相應的parse trees（解析樹）如圖14.1。  圖14.1 hello() 函數的解析樹（parse trees） **準確性（Accuracy）** 由工具實現的重構，必須合理保持程序原有行為。當然，完全的行為保持是不可能達到的，重構總是會給程序帶來一些細微改變。例如重構可能會對程序的運行速度帶來數個微秒的變化，這算是「完全的行為保持」嗎？通常這般微小差異不會對程序造成影晌；但如果程序有嚴格的實時性要求（real-time constraints），這一點點差異就可能導致整個程序出錯。 即使是傳統程序（而非實時系統）也可能被重構破壞。假設你的程序建構了一個字符串，然后使用Java Reflection API 執行以這個字符串命名的函數，那么如果日后你修改這個函數的名稱，程序就會拋出一個異常；重構前的程序不會這樣做。 然而，對絕大多數程序來說，重構可以相當準確。只要「可能破壞重構準確性」的因素都被識別出來，重構技術員就可以避免在不適當時候進行重構，也可以避免對于「重構工具無法修補的程序」錯誤地進行手工修補。