Java经典书籍推荐《重构-改善既有代码的设计》

Java经典书籍推荐《重构-改善既有代码的设计》

《Refactoring: Improving the Designof Existing Code》

Karlon 29 Jun 2012

 

程序经过多年的运行，逻辑变得复杂难懂，难读难以维护，哪怕一点点修改，就会牵一发而动全身。阅读和修改的成本越来越大。解决一个小小的bug，调查问题的时间长过修改和测试的时间10倍甚至更多。在平时阅读别人代码的时候，也遇到过同样的问题。曾经找过，哪里有一本书专门讲解如何更快和更安全的调整现有代码，使日常的维护、开发更加顺畅。

 

接触Java之后，随着学习的逐步深入，读到了这本Martin Fowler的《Refactoring》，收益颇多。

 

如果程序员能够从一开始搭建系统的时候，就好好运用重构的战术，会给自己和整个项目组带来极大益处。

 

重构有些最基本的理论基础，值得深入的学习和研究：

 

1. 程序不可能一次设计成功

 

客户需求会不停地变更，而设计的终极目标就是：不仅让系统现在得以正常运行，还能有足够的韧性，为今后的修改打好基础。程序满足足够的韧性是值得提倡的，这样在后续新功能引入时，可以更加快速和安全的将新功能“塞入”旧有框架之中。就像搭建房子，如果框架结构合理的话，后续的装修，改建可以非常顺利。可是实际情况是程序员不可能一次就设计好系统。设计过于精细和灵活的话，简单的说如果“设计过度“，不仅成本高昂，而且设计出来的“灵活性”日后可能完全应用不上。这个时候就必须有所取舍，在最初的设计中，不做过分的假设，把这些工作延迟到时机成熟的时候。不过分最求韧性和灵活性还有一个明显的好处：可以快速获得可运行的程序版本，对士气的鼓舞极大。要知道，长期专注于抽象的分析和设计，非常消耗精力，有令人沮丧和疲惫的趋势。

 

2. 重构是持续的，伴随整个开发和维护过程

 

对代码的重构可以随时进行，引入新功能时，修改bug时，review代码时。总之，只要看到代码不合时宜，需要进行调整，就可以开始重构。重构的越早，代价越小，需要的时间越少。如果长时间不理会系统携带的“小“瑕疵”，任由其扩散，积累，到最后尾大不掉再进行重构，休整的话，会消耗大量时间。软件系统会慢慢“腐败”，而重构就是阻止其腐败进程的最有效的利器之一。

 

3. 重构以小步幅，快频率的方式运作

相信，多数阅读过别人代码的程序员会遇到这种情形：与其修改目前代码，还不如自己重新推倒重来。于是乎，大刀阔斧，横劈竖砍，对原有代码进行动摇根基性的修改，一次引入好几百个编译错误，然后耗费一整天，逐个排查，修改干净。以为万事大吉了，可以休息了。一运行，并且测试，问题不少，有考虑不周引入的新bug，也有简单的逻辑性错误。然后，再次投入bug修复工作，几个小时过去了。仍然没有得到一个可用的稳定版本，Leader一问，还需要多长时间呀？“马上马上”，又一个小时过去了，仍然没有完成。进度不得不一步步后延，更糟糕的是：稳定版本的确定时间不好估计，没有办法给出一个确切的时间。想要回滚觉得可惜，毕竟已经修改了这么多代码，耗费了这么多经历，要继续的话，稳定版本的时间又无法估测。没有办法，只能熬夜加班了。

 

在《Refactoring》这本书中，作者提出了，小步幅，快频率的工作方式，每次进行小幅改动，保证改动没有引入新bug，不停地快速迭代，直到完成所有的工作为止。这种方式工作，几乎在任何时刻，都可以提供一个稳定的可以工作的版本。这种方式更加安全，对程序员的压力也更小。这里，不得不强调Refactoring的另外一个理论基础，就是“可靠测试环境”。因为要确定小幅改动没有引入bug，必须进行测试。以测试通过与否判断是否引入bug。

 

4. 可靠的测试环境对重构至关重要

Java有单元测试框架Junit，用以编写单元测试，保证class正常运作。一个类是否功能正常，需要针对这个class的单元测试。也就是说，在编写代码，维护代码时，我们不仅要维护软件系统本身，也要维护针对class的单元测试用例。可以想见测试用例会非常庞大，这个代价是值得的，一旦搭建好，后续的收益过程会是持续的。根据书中的说法，创建单元测试用例不仅不会降低工作效率，而是相反。一个修改，如果单单通过肉眼观察，难免失察，而且效率低下，不可重用。对于复杂的软件系统，仅用肉眼观察，或者仅仅通过简陋的main方法探查，难以保证可靠。

 

重构习惯的养成，需要搭建可靠测试环境的习惯的养成在先。这需要时间。

 

5. 代码的“坏气味”

书中列举了各种情形的代码“坏气味”，这预示着程序需要重构。这些分类非常详尽。比如：超大型class，class功能含糊，一个class和另外class关系暧昧，switch分支，等等。

 

6. 大胆修改，稳妥测试

在维护系统时，很可能遇到这种情况：程序员明确知道软件有瑕疵，可是碍于系统的复杂性，唯恐引入新的bug，程序员往往不愿意修改它。因为害怕引入新的问题，而放任程序瑕疵。这是一个不容忽视的问题。程序重构，也需要勇气，对瑕疵和错误进行大胆的修改，而后进行稳妥测试。目标只有一个，得到质量稳定，高效的软件系统。

 

这是一本不可多得的好书，值得一看。