构筑测试系统
测试……一年前，我开发的时候还是很不在乎测试，不过那个时候也没人告诉我测试的重要性。直到意识到要提高自己，学习中看到了那么多提到测试的，所以慢慢的尝试使用（大部分是单元测试），然后深深的爱上了单元测试（其他测试呢，好吧，编程中的确比较少用到其他测试，我比较懒）。
作者在前面反复提到测试在重构中的重要性，这章就是介绍测试的。
自我测试代码的价值：
编码往往只占了开发中的小部分时间，很多时间不是在沟通、设计，就是在找 BUG 。。。专业点，应该叫调试（ debug ）。测试的主要作用就是帮助调试，帮助开发中发现潜在的 BUG ，这样我们就可以少话点时间在调试上了。频繁进行测试是极限编程（下一个学习的内容）的重要一环。
确保所有测试都是自动化，让它们检查自己的测试结果。
一整组测试就是一个强大的 BUG 侦测器，能够大大缩减查找 BUG 所需要的时间。
JUNIT ：
看来 JUNIT 的历史很悠久啊，作者写书的时候就已经很成熟了。我想这个不需要多说了，现在有关 JUNIT 的介绍到处都是。我也喜欢用 JUNIT ，不过看书中的介绍的 JUNIT 的基本使用有点老了，完全忽略吧。
重构前先为需要重构的功能构建好测试用列，在重构中，每次变动都需要进行测试，以确保重构没有给程序带来什么BUG。这个很重要。
大型重构
大型重构的重要性：大型重构没有那些小动作那样立竿见影的效果，不过它可以帮助我们解决那些堆积了很久，影响范围又很大的问题。
Tease Apart Inheritance （梳理并分解继承体系）
用于处理混乱的继承体系——这种继承体系往往以一种令人迷惑的方式组合了数个不同方面的变化（ variations ）。
某个继承体系（ inheritance hierarchy ）同时承担两项责任。
建立两个继承体系，并通过委托关系（ delegation ）让其中一个可以调用另一个。
Convert Procedural Design to Object （将过程化设计转化为对象设计）
可以帮助你解决一个「古典」问题：如何处理程序性代码（ procedural code ）？
你手上有一些代码，以传统的过程化风格（ procedural style ）写就。
将数据记录（ data records ）变成对象，将行为分开，并将行为移入相关对象之中。
Separate Domain from Presentation （将领域和表述 / 显示分离）
将业务逻辑（ business logic ）与用户界面（ user interface ）隔离开来。
某些 GUI class 之中包含了 domain logic （领域逻辑）。
将 domain logic （领域逻辑）分离出来，为它们建立独立的 domain class 。
Extract Hierarchy （提炼继承体系）
则可以将过于复杂的 class 转变为一群 subclass ，从而简化系统。
你有某个 class 做了太多（过多）工作，其中一部分工作是以大量条件式完成的。
建立继承体系，以一个 subclass 表示一种特殊情况。
剩下的
书的第6章到第11章都在介绍重构的各种方法，这些方法的名字大部分都在“代码的坏味道”里面出现过。好多重构工具都提供了这些方法的支持，比如Eclipse就提供了很好的支持。