Martin Fowler 讲述重构的工作流程

《重构：改善既有代码的设计》一书的作者 Martin Fowler 最近在其个人网站上发表了一篇文章，探讨了如何通过各种工作流程来将代码重构融入到我们日常的编程工作当中。

在文章中他还介绍了如何使用各种不同的工作流程，并且建议“为了最有效地进行代码重构，我们需要结合使用所有的重构工作流程，这样才能使不同的流程无缝地融入到开发工作当中”。

Fowler 将重构定义为“……一项用于对既有代码的主体结构进行调整的专门技术，可以在不影响其外部行为的情况下修改其内部结构”。

Joshua Kerievsky 在其著作《重构与模式》中建议：

通过持续地改善代码的设计，我们可以使代码变得越来越容易维护。这与通常所采用的做法形成了鲜明的对比。通常我们很少做代码重构，而是把大量的注意力放在如何方便快捷地添加新功能上面。如果我们养成了持续重构的良好习惯，就会发现代码变得越来越容易扩展和维护。

虽然在文中 Fowler 讲到重构技术现在已经为人们所熟知，但他还是建议大多数的团队仍然需要去更好地了解实施重构过程中可以使用的各种工作流程，以便在各种情况下都能够选择出最佳的流程加以应用 。

基于 Don Roberts 提出的三次法则，网站 SourceMaking描述了需要进行代码重构的下列几种情形。

“第一次做某件事情时，可以只管去做。第二次做类似的事情时，虽不情愿，但总之还是把同样的事情重复又做了一遍。而第三次做类似的事情时，就要进行重构。”

• 当添加新函数时
• 当修复 bug 时
• 当进行代码评审时

Fowler 使用了“两顶帽子”的比喻，向我们解释了有些时候我们是在添加新的功能（添加功能帽子），而另外一些时候我们是在改善既有代码的质量（重构帽子）。这样的比喻还能够作为我们日常编程工作中的提醒，使我们清楚地认识到自己究竟工作在哪种角色下。在文中他还讲到“在编程过程中，我们可能需要在不同的帽子间频繁地转换，可能每隔几分钟就要转换一次，但我们每一时刻只能带一顶帽子”。

借着上面的比喻，Fowler 描述了第一种工作流程，可能也是使用最为广泛的一种流程，名字叫做“使用测试驱动开发进行重构”。这种流程基于以下循环：开始于绿色状态，编写测试用例（现阶段会执行失败），然后编写程序使之能够通过测试，最后再对代码的质量进行改进。来自 planetgeek.ch 的 Urs Enzler 详细描述了测试驱动开发与重构之间的关系。

“捡垃圾式的重构”是下一种工作流程。Fowler 在文中提出，这种流程可以应用在代码中出现大面积混乱段落时的情景。这种流程的基本原理就是“每次都对我们用到的部分代码进行清理，这样会简化我们下次使用时所需要做的清理工作。这种方法甚至还可以使当前要做的修改也变得容易”。

之后Fowler 还详细地解释了“针对代码可理解性的重构”。这种重构旨在使代码变得简单易懂，进而使程序变得易于使用和维护。文章中还引用了一段 Ward Cunningham 的话来补充这一观点：

每当你不得不去搞明白一段代码究竟做了哪些事情的时候，在你的头脑中就会形成对于这段代码功能的一些理解，而一旦形成了这些理解，你就应该把它们固化到代码中，这样其他人就不必对这段代码再从头理解一遍。

文中还描述了其他三种工作流程，Fowler 认为它们与前面所讲的三种流程同样重要：

• “准备性的重构”——当我们开始开发一项新功能时可以采用这种方法。
• “有计划的重构”——当问题代码太多，必须专门花时间来进行重构时可以采用这种方法。
• “长周期的重构”——当我们需要在几轮迭代过程中替换掉一个较大的模块时可以采用这种方法。

你们是否也一直在做代码重构？

查看英文原文： Martin Fowler Presented Workflows of Refactoring

感谢臧秀涛对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。