写在前面

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

 

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

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

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

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

好啦,不说废话了,先展示一下PDF的主要内容:

 

重构,改善既有代码的设计

PDF主要目录展示:

 

 

 

PDF主要内容展示:

第1章:重构,第一个案例

 

第2章:重构原则

 

第3章:代码的坏味道

 

第4章:构筑测试体系

 

第5章:重构名录

 

温馨提示:转发+关注,后台私信【111】或【666】即可~

第6章:重新组织你的函数

 

第7章:在对象之间搬移特性(Moving Features Between Objects)

 

第8章:重新组织数据(Organizing Data)

 

第9章:简化条件表达式(Simplifying Conditional Expressions)

 

第10章:简化函数调用(Making Method Calls Simpler)

 

第11章:处理概括关系(Dealing with Generalization)

 

第12章:大型重构(Big Refactorings, by Kent Beck and Martin Fowier)

 

第13章:重构,复用与现实

 

第14章:重构工具(Rfactoring Tools,by Don Roberts and John Brant )

 

第15章:集成(Put It AlI Together, by Kent Beck)

 

写在最后

如何领取?

——转发+关注我,后台私信【111】或【666】即可免费领取(100%纯免费~)