重构：“为什么”和“怎么做”

近日在“敏捷中国”讨论组展开了一系列关于重构的讨论。一种观点认为，对代码的重构是程序员出于对代码美感的追求而进行的行为。

重构更多的是基于激情，把代码做为艺术品来雕琢。但是不少软件公司工作环境可以很快摧残这种热情。

然而作为软件开发工作的一部分，重构行为显然不应该被归结于“激情”和“艺术”。之所以有这种想法，往往是由于没有一种有效的方式来衡量重构行为的成本和收益，从而不能有效地组织和管理重构行为。在同一组讨论中就有人提出了这个问题：

我想了解一下，大家是否把重构的时间放到sprint的估算里。假设到了代码用户案例测试通过了，操作文档也完成了，如果没有时间重构代码，你们会怎么办？重构的时间，跟追求的度成正比，怎么估算重构的成本？

来自ThoughtWorks的熊节认为，重构的收益体现为修改成本的降低，因此也是可衡量的。

从商业的角度，每段代码，每次修改都带来一定的商业价值，同时每段新代码，每次修改都有它的成本，这个成本随代码质量的下降而上升。当代码质量烂到一定程度，修改代码的成本超过收益，这个软件就没办法继续发展了。重构也有它的成本，它带来的收益是降低修改代码的成本。如果你发现一个程序员一方面抱怨面对变化的需求他不敢动手改代码，另一方面又不想通过重构改善代码质量，你就知道这里必定有什么问题了。

在一篇题为“在大型遗留系统基础上运作重构项目”的文章中，熊节详细说明了如何权衡重构的成本和收益：

和别的任何story一样，重构的story（以及其他“技术债”类型的story）也应该符合INVEST的标准。尤其是，它们的工作量应该得到估算，它们应该按照业务价值排列优先级。因为归根到底，重构（以及其他任何开发任务）都归结为“花在代码上的成本”与“对业务创造的价值”之间的权衡。

按照定义，重构意味着“在不改变功能性行为的前提下改进代码的组织结构”。如果代码基础本身脆弱而没有测试覆盖，重构的成本就会很高，因为你需要花很大力气来确认自己的修改没有改变功能性行为。

如果偿还“技术债”的成本非常高，那么与之对应的业务价值就必须更高，否则偿还这些债务就将得不偿失。其结果是：一段代码，从程序员的角度看来越糟糕，从商业的角度来说就越不应该去动它。

综上所述，如果有人说“这一大堆代码都需要重构”，这样的说法很有可能是值得商榷的。你需要把重构划分成细粒度的、可控的story，为这些重构story制定验收标准，评估它们的优先级，估算它们的工作量，然后逐一实现它们，并且放弃一些得不偿失的重构。

这篇文章还介绍了对遗留系统进行重构的步骤：

经过这个咨询项目，eMAN产品开发团队在原有代码的基础上划分了细粒度的重构story，建立了持续集成环境，并按照共同探索出的节奏，以测试为驱动、以代码质量为导向，不断重构以改进代码质量，并且积累了一些常见问题的解决办法，为大规模遗留系统的重构找出了一条切实可行的路子。

和所有的敏捷实践一样，重构的原则说起来很简单，但实际操作起来总是会有很多困难，需要经验和权衡。你在尝试重构时遇到困难了吗？你有自己的重构经验想要与整个社区分享吗？