写给工程师的代码重构终极指南

作者 ｜ CATE LAWRENCE

译者 ｜ 冬雨

策划 ｜ 蔡芳芳

本指南将带你了解进行代码重构的好处、可能遇到的挑战、可以采用的工具和最佳实践，以及重构和技术债务之间的区别。

我们都在寻找清理代码、降低复杂性和改进功能的方法，重构就是其中之一。

本指南将涵盖以下主题：

• 重构是什么？

• 重构的好处是什么？

• 技术债务与重构

• 重构度量

• 代码重构的示例

• 代码重构的工具

• 重构和对技术经理的挑战

• 高级管理层对重构的支持

• 团队支持和重构：冲刺还是马拉松？

• 文档和重构

什么是重构？

关于重构，Martin Fowler（https://martinfowler.com/aboutMe.html）写过两本的书，按照他的说法：

“重构是改变软件系统的过程，这一过程改变的不是代码的外部行为，而是其内部结构。这是一种清理代码、尽可能降低引入 bug 机率的方法。从本质上说，进行重构时，是你在代码编写之后改进设计。”

重构的好处是什么？

重构代码有许多好处。它将混乱、不正确和 / 或重复的代码变成整洁的代码。当多个开发人员贡献他们自己的代码时，可能会出现标准化的问题，它正可以解决这一问题。重构可带来更好的可读性，并改善源代码的可维护性以及整体的结构和功能。重构可以使代码更易于扩展和添加新的特性。删除不必要的部分（如重复的部分），也可以使代码使用的内存更少、执行的速度更快。

例如，在 2014 年，Kickstarter 工程师面临着一项挑战，随着用户数量呈指数增长，导致查询性能急剧下降。为了应对此问题，他们重构了一个 MySQL 到 Redis 的查询，减少了典型的 100ms 以上的加载时间，从而减少了加载时间的方差，总体上提升了网站的速度。

技术债务与重构

简单来说，重构是一种消除或减少技术债务的方法。重构对于维护长期的代码质量、安全性和性能至关重要。如果没有定期进行重构，开发商将背负巨额技术债务（https://www.stepsize.com/blog/complete-guide-to-technical-debt）。如果不断地错过代码重构的时机，这种债务也会不断地增加，从而使新的开发越来越困难，特别是在遗留代码上的开发。

重构度量

使用指标可以让你对真正需要处理的代码进行优先级排序。它能防止你试图一次做所有的事情，让你先专注于最重要的任务。

此外，你需要度量标准来证明代码重构的有效性——这不仅仅是关于更改低效代码的，而是关于更改低效代码以增加价值的。要获得真正的价值，你需要单元测试 (例如失败的单元测试数量) 和功能测试。其他度量包括发现更少的 bug 和降低圈复杂度（https://en.wikipedia.org/wiki/Cyclomatic_complexity）——重构的目标应该是降低复杂度。高度复杂的方法或函数 (例如超过 350 行) 是很好的重构目标。

在工作流程和任务方面，也应考虑如何让重构适应更广泛的团队目标或里程碑。其中，应该包括更小的代码大小和更容易理解的代码。

代码重构的示例

代码重构的例子有很多（https://refactoring.com/catalog/），本文受篇幅所限，只关注其中的几个：

• 红、绿、重构

重构与单元测试有着紧密的联系。最常见的一种形式是测试驱动开发 (TDD)，现在一提到敏捷方法就会提到它。它是指在编写代码之前先编写测试。本质上，测试应该驱动编程，说明代码应该做什么。

红、绿、重构是一种 TDD 实例：

—红色：写一个没有实现代码的测试套件，确保它失败。

—绿色：编写实现代码，让那个测试套件通过。

—重构：寻找优化和改进代码的方法。

• 提取方法

  (又名提取函数（https://refactoring.com/catalog/extractFunction.html）)

将一段代码从一个现有的方法移动到一个新方法中，新方法的命名要能清楚解释其功能。这种技术有助于降低代码的复杂性和提高代码的可读性。

• 提取变量

（https://refactoring.com/catalog/extractVariable.html）

如果遇到难以理解的表达式，或者表达式在代码的多个地方重复，那么提取变量的重构方法可以将这样一个表达式结果或其部分结果放置到一个单独的变量中，这样的变量不那么复杂，也更容易理解。这可以减少复杂性和代码重复。

• 抽象分支

（https://www.martinfowler.com/bliki/BranchByAbstraction.html）

抽象分支是为了以渐进的方式对软件系统进行大规模的变更，使你可以在变更的同时定期发布系统。这消除了在分支上重构代码的复杂性，否则当你试图合并代码时，可能会出现问题。

• 组合方法

（https://scrutinizer-ci.com/docs/refactorings/compose-method）

过长的代码很难理解，也很难更改。组合方法指的是一系列可用于简化方法和删除重复代码的措施。这包括内联方法、内联临时变量、用查询替换临时变量（https://refactoring.com/catalog/replaceTempWithQuery.html）、拆分临时变量（https://refactoring.com/catalog/splitVariable.html）和消除对参数的赋值。

用查询替换临时变量示例：原代码：

const basePrice = this._quantity this._itemPrice;if (basePrice > 1000) return basePrice 0.95;else return basePrice 0.98;

重构为：

get basePrice() {this._quantitythis._itemPrice;}...
if (this.basePrice > 1000) return this.basePrice 0.95;else return this.basePrice 0.98

拆分临时变量代码示例：原代码：

let temp = 2 (height + width);console.log(temp);temp = height width;console.log(temp);

重构为：

const perimeter = 2 (height + width);console.log(perimeter);const area = height width;console.log(area);

代码重构的工具

你是否需要专门的工具来进行重构？Martin Fowler 说，自动化工具会有所帮助，但不是必需的。他指出：

许多语言的 IDE 都有自动化完成许多常见重构的功能。它们是我的工具包中非常有价值的一些工具，它们可以让我更快地进行重构。但这些工具不是必需的——我经常在没有工具支持的情况下使用编程语言工作，在这种情况下，我依赖于采取更小的步进，并使用频繁的测试来发现错误。”许多开发环境自动化了那些机械化的重构操作。主要的代码重构工具有：

• Visual studio intellicode

• Eclipse IDE

• Spring Tool Suite 4

• Rider

• IntelliJ IDEA

• SonarQube

重构和对工程经理的挑战

有些问题会导致需要重构，为解决这些问题，需要探索公司是如何运作的。在开始重构之前，回答以下几个问题：

• 什么任务优先级最高？

• 开发的速度是什么样的？

• 开发人员是否感到快速交付代码很有压力？

• 有哪些处理技术债务的流程？

• 进行了哪些类型的代码评审？

• 你的团队是否具备相应的重构技能？

• 公司针对文档的标准是什么？

如果不解决导致需要重构的根本问题，问题只会扩散。

高级管理层对重构的支持

在你的公司，基础设施和维护方面的投资可能不受待见。有些人会想当然地认为，花费在重构上的时间就是占用了做新工作的时间。但我们有必要着眼于重构所带来的更大好处，以及它们与工作流、客户、收入和业务增长之间的关系。重构如果做得好，可以改进代码，使其能够很好地运行，从而交付有效的更新和趋势特性，从而吸引新客户和回访客户。这就是软件公司如何在成功发布产品后保持竞争力的方式。

更好的做法是，量化团队当前花费了多少时间修复原始代码中的错误或 bug，从而从高级管理人员那里获得对重构的支持。具体一点，是每天一个小时吗？还是一天两个小时？坚持记录至少一周，你可能会惊讶地发现你的团队每年花费了好几周甚至好几个月的时间来修复遗留代码。

团队支持和重构：冲刺还是马拉松？

你的团队很难接受重构吗？一提到它，大家就会抱怨吗？成功重构的最显著标志是有计划的、有目的的和文档化的措施。Ron Jeffries 是极限编程软件开发方法论的三位创始人之一，他把重构比作清理一块地（https://ronjeffries.com/xprog/articles/refactoring-not-on-the-backlog/）：

“我们先犁好土地，清除杂草，然后再去播种，也就是构建下一个功能，而不是绕过所有的杂草和灌木丛。”

然而，他强调，糟糕的代码需要很长时间来清理，他建议首先要经过充分地思考，而不是一头直接扎进去：

“我们改进我们当前用得到代码，忽略那些用不到的代码。很可能，我们下一次会再回来看这块代码。通常在同一个冲刺中，我们会发现后续功能实际上使用了我们之前清理过的区域。我们马上就从增量重构中获益了。如果我们等着大规模地实施，就需要投入更多的精力，同时也推迟了产出收益的时间，很可能会把精力浪费在不会带来收益的地方。”

产品工程师和 CTO Andreas Klinger

（https://klinger.io/post/183107642120/refactoring-larger-legacy-codebases）是“周五处理”的粉丝。

“周五处理的原则很简单：除非你当前的项目很忙，否则就利用周五做一些小的改进。让工程师选择他们要做的工作。不要因为太过细致的管理导致大家失去工作的乐趣。一些人会尝试新的类库。有些人会消除待办事务中的缺陷。这两个都很好。试着促使任务平衡。”

无论你的方法是什么，都需要用心思考。问问你的团队什么代码最妨碍他们的效率。

• 修改什么代码对其他代码的影响最大？

• 修改什么将带来最大的回报？

谁都不可能在重构上花费大量的时间而牺牲其他项目，但是不要低估常规的、一贯的、专门的小型重构的影响。积沙成塔，一点一滴堆积起来就会带来巨大的好处。

文档和重构

标准化命名约定之类的文档可以确保每个人形成共同的认知。施乐高级开发人员在研究重构时发现，缺乏文档是最大的挑战之一。

将你重构所做的工作记录下来，可以跟踪所花费的时间，并为未来的团队成员提供上下文。同时，把你取得的成功记录下来——重构中取得的最大的胜利是什么？这些可以进行同行评审吗？

原文链接：

The Ultimate Engineer's Guide to Code Refactoring

（https://www.stepsize.com/blog/the-ultimate-engineers-guide-to-refactoring）

译者简介：

冬雨，小小技术宅一枚，从事研发过程改进及质量改进方面的工作，关注编程、软件工程、敏捷、DevOps、云计算等领域，非常乐意将国外新鲜的 IT 资讯和深度技术文章翻译分享给大家，已翻译出版《深入敏捷测试》、《持续交付实战》。

今日好文推荐

InfoQ 写作平台欢迎所有热爱技术、热爱创作、热爱分享的内容创作者入驻！

还有更多超值活动等你来！

扫描下方二维码

填写申请，成为作者

开启你的创作之路吧~

点个在看少个 bug 👇