16.7　重构

什么是重构呢？Martin Fowler在“Refactoring：Improving the Design of Existing Code”一书对重构定义^[1]如下。

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.

重构是采用这样一种方式改变软件系统的一个过程：它不改变代码的外部行为，但是提高了内部结构的质量。

重构是一个持续过程，提炼模型也属于重构，重构不仅能够提高代码质量，还能偿还技术债务^[2]，为以后新功能的扩展提供了可能性。

关于如何进行重构，大家可以好好研读Martin Fowler的这本书籍，它详细讲述了重构代码的过程。

但是，重构绝对不等于推翻了重做，有相当一部分初学者甚至一些所谓的“资深”开发人员可能由于追求完美的“偏执”所致，他们都喜欢推翻了重做。

重新开发虽然可以规避之前的一些拙劣的设计，但是在重用之前的健壮代码上会大打折扣；

而且，由于之前的拙劣设计，代码也不易阅读，为移植和重写这些拙劣代码带来了问题，往往因为不理解其中的“特殊含义”而重写的逻辑不能很好运行；

另外，和一般的重构一样，新的代码总会引入新的未知问题。

总之，重构并不等于推翻了重做，它也不是重构的最好办法，做推翻重做决定时一定要慎重。

一个良好的项目，开发步骤往往是由慢变快的，起步比较慢，在往后的迭代开发过程中，会变得越来越快；而一个急功近利型的项目往往一开始就快速启动，在随后的开发中，过分地强调了快速发布，导致开发了很多不可扩展代码，随着新的功能不断加入，开发设计变得越来越拙劣，项目也变得越来越慢。如果你的项目目前处境是这样，那么最好停下脚步，考虑是否要花点时间对它进行重构。

我们既要避免轻率地“推翻了重做”，也要避免因为安于现状而导致项目陷入泥沼。

[1]参见该书的前言部分对重构的定义。

[2]Ward Cunningham于1992年在自己的一篇实验报告里引入这个比喻。Vikas Hazrati在如下链接里对技术债务进行了归纳和讨论：http：//www.infoq.com/news/2009/10/dissectingtechnicaldebt