比尔：也就是说，你花在写测试上的时间，可以因为不用修补漏洞而补回来。
马丁：我能在一天之内就把时间补回来，因为花在跟踪调试上的时间大大减少了。花在测试上的成本很快就能收回。随之而来的还有其它好处。
比尔：假如一段代码根本没有测试，那么写测试的成本还能很快收回么？
马丁：这种情况需要较长的时间。我不建议你花上整整两个月的时间，就是用来写测试。但我认为，通过添加一些测试，你能很快 获得回报，因为你开始发现问题了。如果你把测试集中在你需要做改动的代码部分，那么当你犯错误的时候，测试会告知你这些错误。显然，全面综合的测试会使你 受益最大；但是，就算只写几个测试，你也会从中受益。
重构与效率
比尔：你说过单元测试可以帮助你提高效率，你还说过重构的好处之一就是能够更快地编程。那么，重构是如何帮助你提高编程速度的呢？
马丁：因为一个设计良好的程序，修改起来会更容易。程序的设计越好，修改起来就越容易，从而提高了效率。
重构与性能优化
比尔：你在书里写道，你之所以做重构，并不是出于好玩，而是因为“有些与程序有关的事情，如果不做重构，就无法做到；只有做了重构，才能办到。”那么，你所指的这些事情，除了对程序进行改动，还有哪些事情呢？
马丁：对程序进行改动是主要的动因。我们不得不经常对软件作出一些改动——只要这个软件还在使用。重构是用来改善设计的。 我们需要一个好的设计以使任何改动都更容易些。重构跟性能优化有些类似，都是在行为不变性（behavior-preserving）前提下的改进。不 过，性能优化的步骤有异于重构，整个过程也有所不同，因为性能优化的驱动要素是性能分析（profiling）。
比尔：也就是说，重构所作的改动，不会增加或改变功能，而是为了程序更清晰，这样，将来就可以容易地做出改动。而性能调优的相似之处在于，其所作的改动除了缩短执行时间以外，也不会改变程序的功能。
马丁：对。它们有相似之处。不过，我一般还是把它们看成是两个很不一样的概念。
重构与设计
比尔：您在《重构》一书中写道：“重构可以帮助我们改进软件的设计。”那么，重构是如何改进设计的呢？
马丁：我无法笼统地回答这个问题。不过你可以分析单个的重构方法，来看看它是如何改进设计的。比如，提取方法（Extract Method）通过把一个很长的、令人费解的方法拆分成一些小方法来改进设计。改进后的方法读起来就像是一份文档——一张调用那些小方法的列表。
每种重构方法都会对针对某些特定的设计元素做出改进。应用的时候要具体情况具体分析。很多重构方法都能找到相对立的另一个重构方法。比 如，如果一个方法，除了方法本身的代码所表达的意义之外，没有任何附加的含义，那么你可能会内联它。内联方法（Inline Method）与提取方法就是对立的。很多时候，到底应用哪种方法取决于具体情况。
重构与查错
比尔：你在《重构》一书中还声称，重构可以帮助你发现漏洞。重构是如何做到这一点的？
马丁：我想，重构可以从几方面帮助你发现漏洞。有时候，当你让程序变得易懂时，漏洞自然而然地就显现在你面前。你一边做着 重构，一边对自己说，“等等，假如给定某种条件，结果会是什么呢？”我就是这样发现了很多漏洞，还有很多其他人也都如此。重构使得事情一瞬间清晰起来，因 而你能够一眼就看出漏洞所在。
当你在修补一个漏洞而代码又晦涩难懂时，重构也能够帮你发现问题所在。通常，当你在调试一段代码的时候，对之进行重构也相对容易些。重构后，你就可以轻易地发现漏洞在哪里。这种清理使得漏洞更容易被暴露出来。
针对包含漏洞的代码段编写单元测试，是一种很好的调试技术。其带来的好处，不仅仅是让你对代码的理解更深刻，还让你建立起测试库，从而意味着将来不会有问题发生。
重构与重写
比尔：在《重构》一书中，你列举了重构可能会遇到的几个问题，其中有一个是说，在某些情况下不应该做重构。那么，如何判断什么时候应该彻底抛弃现有代码从头开始，而不是选择重构？
马丁：答案是——我也不知道。如果你有一堆乱七八糟的代码且又没有测试，那么你最好是扔掉它们从头开始，否则你就得重新做 所有的测试。反之，如果你有一堆乱七八糟的代码同时还有很多测试的话，情况就不一样了。假如代码中满是漏洞，那么在行为不变性下，不管怎么变换，那些漏洞 都会被保留下来。这时，是否重构就是一个值得争论的问题。我想，这个问题的答案也会随着你对重构熟悉程度的深入而改变。随着对重构越来越有信心，你可能会 对以前想要重写的一些东西改用重构，因为你有更强的重构能力了。
比尔：我曾经有过一次经历，和另外一个咨询师一起努力使一个有问题的应用运转起来。我决定把我所负责的那段代码彻底丢弃， 然后从头开始。而另一位咨询师试图重构他所负责的代码。但结果却是，他那部分代码最终也未能稳定运行。最后，我接手了他的工作，把原来的代码丢掉，从零开 始重写了一遍。这次经历说明，在某些时刻，如果代码完全没有结构，那么重写是比重构更有效的一种方法。
马丁：在决定重写代码之前，也许值得花些时间在重构上，来看看能做多少改进。
