### 重构工具的实用标准（Practical Criteria ） 工具之所以被创造出来，是为了帮助人们完成工作。如果工具不能适应人们的工作方式，人们就不会使用它。重构工具的最重要标准（要求〕就是：和其他工具共同集成出重构过程（refactoring process ）。 **速度（Speed）** 重构前的分析和必要调整，可能会耗费较多时间，因为它们有可能非常复杂。工具设计者必须考虑这些前期工作对时间和准确性（accuracy）的影响。如果重构前需要大量准备工作，程序员就不会使用自动化重构工具，他们宁可手工进行重构。是 的，开发速度总是很重要的。在开发Refactoring Browser 的过程中，有数个重构手 法并没有被我们实现出来，正是因为我们无法在可被接受的时间内安全实现它们。 但是我们的工作仍然颇有成绩，绝大多数重构都可以在极短时间内以极高的准确度完成。计算器科学家总是但愿能够覆盖「特定函数无法处理之（所有〕边界情况」，但事实上绝大多数程序并不涉及那些边界情况。因此，简单而快速的作法便可美好地胜任这些工作。 如果重构前的分折需要花费太长时间，一个简单的解决办法就是：直接询问程序员你所需要的信息。这种办法把「保证准确性（accuracy）」的责任交给了程序员， 于是分析过程可以进行得更快一些。很多时候程序员其实都知道必要信息。尽管这种办法可能不够安全（因为程序员有可能犯错），但「错误」的责任也落了一部分在程序员肩上。讽刺的是，这竟然使程序员更有可能使用这些工具，因为他们无需倚赖程序的探询（错误尝试，heuristic ）来收集信息。 **Undo（撤销）** 「自动化重构」令开发者得以采用探索方式（exploratory approach ）进行设计。你 可以试着把代码移到他处，观察新设计方案是否有效。由于我们假设重构都能够保持程序的原本行为，所以反向重构（亦即对原重构的撤销）也应该不影响程序的原本行为。Refactoring Browser 的早期版本并没有Undo（撤销）功能，这使用户无法 对重构充满信心。重构的撤销相当困难。但是很多时候我们偏偏必须找出程序重构前的版本，重新开始，这可真够讨厌的。于是我们后来为Refactoring Browser 加上 了Undo 功能，又克服了一个障碍。现在，我们可以放心尝试，不会遭受任何惩罚， 因为我们总是可以回到原先的任何一个版本。我们可以建立新的class、搬移函数、 观察代码的行为，而后又改变想法，走另一个完全不同的方向。这一切都可以非常快速地完成。 **与其他工具集成（Integrated with Tools）** 过去十年以来，集成开发环境（IDE）已经成为绝大多数开发项目的核心工具。IDE 将编辑器、编译器、连接器、调试器以及程序开发所需的其他所有工具，都集成于一起，开发者可以在同一个环境中极方便地使用所有这些工具。Refactoring Browser 早期版本是一个独立于标准Smalltalk 开发工具之外的独立工具，我们发现根本没人使用这样的产品，就连我们自己都不用。但是把重构功能直接集成到Smalltalk Browser之后，我们就开始经常使用它。「是否就在吾人指尖」造成了这 一切的不同。