在我们的“Ask The Experts”会话中，Brad Irby回答了这一问题：如何重构问题未发生之前防止它？

导致重构问题的最主要原因并不是代码，而是因为缺乏合适的工具。重构几乎一直都包含重命名变量和方法、改变方法声明，以及移动周边的一些事物。试图手工进行这些改变很容易会导致重大灾难。例如，你改就了一个本地方法的变量名字，但新的方法却与一个类同名。重构工具应该生产一个警告，在重命名时，但手动更改却不会有提醒。从一开始就要对合适的工具进行投资。

在代码中，一个常见的引起重构问题的代码技术是，直接使用数据库查询结果，而不是使用中间层的类。在旧的，没有对象关系映射层中，使用域或数字访问数据库结果很常见。这很危险，因为由于打字引起的错误在构建时期将不会显露，只有在运行时，当应用由于缺少域或不良数据类型而崩溃时才会显现。对于任何使用这一数据访问方法的遗留系统的首要重构是引入仓储模式。这也将有助于下一个常见的问题：缺乏单元测试。

为也验证更改而做缺少单元测试的重构是自找麻烦。缺少单元测试安全保障的重构，最明显的危险是，在重构代码中引入未被检验的缺陷。然而，当遗留代码已经有了未检测制缺陷，且直到重构都不会暴露时，就出现了另一个危险的。在这种情况下，当根源下真的在代码中，且没被触及到时，最自然的反应是通过搜索最近的改变来查找错误。通过最先为现有的代码创建一套单元测试，这些预存在的缺陷，可以在所有逻辑改变之前检测到。

最后，重构那些已经存在许多外部接口的代码容易产生错误，尤其是松散型和字符串参数。重构接收系统可能会引入缺陷，当外部系统发送一个特别数字集时，这一数字集一直有效，且在接收方意料之外。这些缺陷在构建周期中不会被发现，因此它们只会发生在整个QA周期，甚至是生产中。对此的一个最好的解决方法是捕捉到所有数据，在特定时间量中两个系统之间传输的数据，重构接收系统从而可测试，然后使用这一捕捉到的活跃数据在单元测试中，来确保重构可以正确处理实时流量。