### 尋找引用點 很多重構都要求你找到對于某個函數（methods）、某個值域（fields）或某個class的所有引用點（指涉點）。做這件事的時候，記得尋求計算機的幫助。有了計算機 的幫助，你可以減少「遺漏某個引用點」的幾率，而且通常比人工査找更快。 大多數語言都把計算機代碼當作文本文件來處理，所以最好的幫手就是一個適當的文本查找工具。許多編程環境都允許你在一個文件或者一組文件中進行文本查找，你的查找目標的訪問控制（access control〕會告訴你需要查找的文件范圍。 不要盲目地「查找-替換」。你應該檢查每一個引用點，確定它的確指向你想要替換的東西。或許你很擅長運用查找手法，但我總是用心去檢查，以確保替換時不出錯。要知道，你可以在不同的classes中使用相同函數名稱，也可以在同一個class中使用名稱相同但簽名（signature）不同的函數，所以「替換」出錯機會是很高的。 在強型別（strongly typed）語言中，你可以讓編譯器幫助你捕捉漏網之魚。你往往可以直接刪除舊部分，讓編譯器幫你找出因此而被懸掛起來（dangling）的引用點。這樣做的好處是：編譯器會找到所有被懸掛的引用點。但是這種技巧也存在問題。 首先，如果被刪除的部分在繼承體系（hierarchy)中聲明不止一次，那么編譯器也會被迷惑。尤其當你處理一個被覆寫〔overridden）多次的函數時，情況更是如此。所以如果你在一個繼承體系中工作，請先利用文本查找工具，檢查是否有其他class聲明了你正在處理的那個函數。 第二個問題是：編譯器可能太慢，從而使你的工作失去性能。如果真是這樣，請先使用文本查找工具，最起碼編譯器可以復查你的工作。只有當你想移除某個部分時，才請你這樣做。常常你會想先觀察這一部分的所有運用情況，然后才決定下一步。 這種情況下你必須使用文本查找法（而不是倚賴編譯器〉。 第三個問題是：編譯器無法找到通過反射機制（reflection）而得到的引用點。這也是我們應該小心使用反射的原因之一。如果系統中使用了反射，你就必須以文本查 找找出你想找的東西，測試份量也因此加重。有些時候我會建議你只編譯，不測試，因為編譯器通常會捕捉到可能的錯誤。如果使用反射〔reflection），所有這些便利都沒有了，你必須為許多編譯搭配測試。 某些Java開發環境（特別值得一提的是IBM的VisualAge）承受了Smalltalk瀏覽器的影響。在這些開發環境中你應該使用菜單選項（menu options）來查找引用點，而不是使用文本查找工具。因為這些開發環境并不以文本文件保存代碼，而是使用―個內置數據庫。只要習慣了這些菜單選項，你會發現它們往往比難用的文本查找工具出色得多。