写在前面

重构，绝对是写程序过程中最重要的事之一。在写程序之前我们不可能事先了解所有的需求，设计肯定会有考虑不周的地方，而且随着项目需求的修改，也有可能原来的设计已经被改得面目全非了。更何况，我们很少有机会从头到尾完成一个项目，基本上都是接手别人的代码，即使这个项目是从头参与的，也有可能接手其他组员的代码。我们都有过这样的经验，看到别人的代码时感觉就像屎一样，有一种强烈的想重写的冲动，但一定要压制住这种冲动，你完全重写，可能比原来的好一点，但浪费时间不说，还有可能引入原来不存在的Bug，而且，你不一定比原来设计得好，也许原来的设计考虑到了一些你没考虑到的情况。所以，我们要做的是重构，从小范围的重构开始。

重构不只可以改善既有的设计，还可以帮助我们理解原来很难理解的流程。比如一个复杂的条件表达式，我们可能需要很久才能看明白这个表达式的作用，还可能看了好久终于看明白了，过了没多长时间又忘了，现在还要从头看，如果我们把这个表达式运用Extract Method抽象出来，并起一个易于理解的名字，如果函数名字起得好，下次当我们再看到这段代码时，不用看逻辑我们就知道这个函数是做什么的。

PDF是用Java写的，而且Java的版本很老。

但是有些东西还是很值得注意的，比如封装集合(Encapsulate Collection)，当调用者请求一个类的一个集合对象时，我们最好不要返回这个集合对象，而是返回这个集合对像的一个不可修改的副本，并增加添加/移除数据的函数。比如Android开发的Adapter，我们经常会为了方便给Adapter添加返回数据集合与设置数据集合的方法，但这是不安全的，我们不能确定调用者获得这个集合后会做什么事情，如果调用者修改了这个集合的内容我们也对其一无所知，在Android中，如果调用者在非UI线程获得了Adapter列表的数据并修改是会出问题的。

重构前，先检查自己是否有一套可靠的测试机制。这些测试必须有自我检验的能力，毕竟重构可能破坏掉一些东西，我们要靠测试帮助我们发现这些问题，不要因为测试无法捕捉所有bug就不写测试，因为测试的确可以捕捉到大多数bug。