### 寻找引用点 很多重构都要求你找到对于某个函数（methods）、某个值域（fields）或某个class的所有引用点（指涉点）。做这件事的时候，记得寻求计算机的帮助。有了计算机 的帮助，你可以减少「遗漏某个引用点」的几率，而且通常比人工査找更快。 大多数语言都把计算机代码当作文本文件来处理，所以最好的帮手就是一个适当的文本查找工具。许多编程环境都允许你在一个文件或者一组文件中进行文本查找，你的查找目标的访问控制（access control〕会告诉你需要查找的文件范围。 不要盲目地「查找-替换」。你应该检查每一个引用点，确定它的确指向你想要替换的东西。或许你很擅长运用查找手法，但我总是用心去检查，以确保替换时不出错。要知道，你可以在不同的classes中使用相同函数名称，也可以在同一个class中使用名称相同但签名（signature）不同的函数，所以「替换」出错机会是很高的。 在强型别（strongly typed）语言中，你可以让编译器帮助你捕捉漏网之鱼。你往往可以直接删除旧部分，让编译器帮你找出因此而被悬挂起来（dangling）的引用点。这样做的好处是：编译器会找到所有被悬挂的引用点。但是这种技巧也存在问题。 首先，如果被删除的部分在继承体系（hierarchy)中声明不止一次，那么编译器也会被迷惑。尤其当你处理一个被覆写〔overridden）多次的函数时，情况更是如此。所以如果你在一个继承体系中工作，请先利用文本查找工具，检查是否有其他class声明了你正在处理的那个函数。 第二个问题是：编译器可能太慢，从而使你的工作失去性能。如果真是这样，请先使用文本查找工具，最起码编译器可以复查你的工作。只有当你想移除某个部分时，才请你这样做。常常你会想先观察这一部分的所有运用情况，然后才决定下一步。 这种情况下你必须使用文本查找法（而不是倚赖编译器〉。 第三个问题是：编译器无法找到通过反射机制（reflection）而得到的引用点。这也是我们应该小心使用反射的原因之一。如果系统中使用了反射，你就必须以文本查 找找出你想找的东西，测试份量也因此加重。有些时候我会建议你只编译，不测试，因为编译器通常会捕捉到可能的错误。如果使用反射〔reflection），所有这些便利都没有了，你必须为许多编译搭配测试。 某些Java开发环境（特别值得一提的是IBM的VisualAge）承受了Smalltalk浏览器的影响。在这些开发环境中你应该使用菜单选项（menu options）来查找引用点，而不是使用文本查找工具。因为这些开发环境并不以文本文件保存代码，而是使用―个内置数据库。只要习惯了这些菜单选项，你会发现它们往往比难用的文本查找工具出色得多。