一份关于代码重构的简明指南
共 3696字，需浏览 8分钟
·
2021-04-12 15:22
【编者按】重构是一种对软件进行修改的行为，但它并不改变软件的功能特征，而是通过让软件程序更清晰，更简洁和更条理来改进软件的质量。
作者 | Alex Omeyer
译者 | 弯月 @CSDN（ID：CSDNnews）
以下为译文：
我们一直在寻找各种方法来清理代码、降低复杂性和改善功能。而重构为我们指明了前进的方向。
本文涵盖的主题如下：
什么是重构？
重构有什么好处？
技术负债与重构
重构的指标
代码重构示例
重构代码的工具
重构与工程经理的难题
高级管理层对重构的支持
团队支持与重构：一个Sprint还是马拉松？
文档与重构
什么是重构？
Martin Fowler曾出版了两本有关重构的书籍，他认为：
重构指的是，在不改变代码的外部行为，只改善其内部结构的方式下，修改软件系统的过程。重构是一种有条理的清理代码的方式，可以最大程度地减少引入bug的机会。本质上，重构意味着在代码编写完成后，改进代码的设计。
重构有什么好处？
重构源代码有数不清的好处。首先，重构可以将混乱、不正确和/或重复的代码转换成整洁的代码。它可以解决多位开发人员协同工作时可能引发的代码标准化问题。重构可以提高可读性，改善源代码的可维护性以及整体结构和功能。重构可以使代码更易于扩展和添加新功能。删除不必要的代码（比如重复代码）可以减少代码所使用的内存，并加快执行速度。
例如，在2014年，Kickstarter的工程师面临着一个巨大的挑战：由于用户数量呈指迅速增长，导致查询性能下降。为此，他们将MySQL查询重构为Redis，减少了100毫秒的加载时间，从而减少了加载时间的差异并提高了网站的整体速度。
技术负债与重构
简而言之，重构是消除或减少技术负债的一种方式。
重构对于长期维持的代码质量、安全性和性能至关重要。如果没有定期的重构，开发人员就会承受巨大的技术负债。重构代码的机会越少，技术负债就会越多，开发新功能也会变得越来越难。
重构的指标
我们可以通过各种指标，衡量重构代码的优先级。在指标的帮助下，我们可以有条不紊地计划重构，每一次都专心完成最重要的任务。
此外，你需要通过指标来衡量重构的效果。我们不仅需要重构低效的代码，而且还可以通过修改低效代码增加价值。为了获得真正的价值，你需要进行测试，包括单元测试和功能测试。除此之外，还有一些其他方面的指标，比如发现的bug数减少，以及降低循环复杂性（重构的目标是降低复杂性）。高度复杂的方法或功能（比如超过350行的方法或功能）就是良好的重构对象。
此外，我们还需要考虑，如何将重构融合到更广泛的团队目标或有关工作流和任务的里程碑中。
代码重构示例
代码重构的示例非常多，为了简洁起见，我们介绍以下几种：
红色，绿色和重构
重构与单元测试息息相关。最常见的形式之一就是敏捷方法固有的测试驱动开发（Test-Driven Development，即TDD）。你可以在编写代码之前先编写测试。从本质上来说，应该由测试来驱动程序，说明代码应该执行的操作。
红色，绿色和重构是测试驱动开发的一个示例：
红色：编写没有实现代码的测试套件，必然会失败。
绿色：编写实现代码，刚刚好可以通过测试套件。
重构：寻找优化和改进代码的方法。
提取方法（又名提取函数）
将代码片段从现有方法移到新方法中，而新方法的名称明确说明了其功能。这种技术有助于降低复杂性并提高代码的可读性。
提取变量
如果遇到难以理解的表达式，或者该表达式在整个代码中重复了多次，则可以通过提取变量重构，将表达式或其中一部分放入一个复杂度较低且更易于理解的变量中。这样可以减少复杂性和代码重复。
按抽象建立分支
按抽象建立分支可以逐步对软件系统进行大规模地修改，而你则可以一边修改代码，一边定期发布系统。这种方法可以降低在分支上重构代码的复杂性，避免在合并代码时出现问题。
方法组合
代码过长不便于理解，而且也不方便修改。方法组合指的是一系列的操作，将方法改成顺序结构并删除重复的代码。这些操作包括内联方法、内联模板、用查询代替模板、拆分临时变量以及删除对参数的赋值等。
重构代码的工具
你需要专业的重构工具吗？Martin Fowler表示，自动化的工具有帮助但不是必需的。他指出：
“许多语言都有IDE，可以自动执行许多常见的重构。这些是非常有价值的工具，可以帮助我更快地重构代码。但是，这些工具不是必不可少的，我经常在没有工具支持的情况下编写程序，每次只迈出一小步，并通过频繁的测试来发现错误。”
许多开发环境都可以自动化重构，一些常见的重构工具包括：
Visual studio intellicode
Eclipse IDE
Spring Tool Suite 4
Rider
IntelliJ IDEA
SonarQube
重构与工程经理的难题
为了解决引发重构需求的问题，首先我们需要弄清楚公司的运营方式。在着手重构之前，请先回答下列几个问题：
哪些任务最优先？
开发的速度如何？
开发人员是否感觉到了快速交付代码的压力？
解决技术负债的流程都有哪些？
实施了哪些类型的代码审核？
团队成员是否具备适当的重构技能？
公司的文档标准是什么？
如果不解决引发重构需求的根本问题，那么问题只会愈演愈糟。
高级管理层对重构的支持
你们公司可能并没有在基础设施和维护上投入太多资金。
可能会有人说，应该将花费在重构上的时间投入到新功能开发上。
但是，我们仍然应该看一看重构的好处，以及它们与工作流程、客户、收入和业务增长的关系。重构得当可以改善代码，交付有效更新以及急需的功能，从而吸引新客户和回头客。即使在成功发布产品之后，软件公司也可以通过这种方式保持竞争力。
为了获取高层管理的支持，还有一个更好的方法，即量化团队当前花费在修复原始代码中的错误或bug上的时间。具体一点，比如每天一个小时？每天两个小时？持续记录一个星期，你就会惊讶地发现原来团队每年需要花费数周或数月时间来修复遗留的代码。
团队支持与重构：一个Sprint还是马拉松？
很难在团队内部开展重构工作？提及重构就会哀声载道？顺利开展重构的最重要的标志就是有计划、有目标以及有文档记录的行动。Ron Jeffries（极限编程的三大创始人之一）将重构比喻为清道：
“花些时间清出一条道来，那么下一次我们就可以直奔我们要构建的下一个功能，而无需绕过杂草和灌木丛。”
但是，他强调指出，糟糕的代码需要花费很长的时间来清理，而且重构应该经过深思熟虑：
“如果我们只改进手头的代码，而忽略目前不涉及的代码，那么以后必然会走回头路。”
在同一个Sprint中，我们经常发现后面的功能用到了我们之前清理过的代码。我们就会立即享受重构的好处。如果我们等积攒了一堆技术负债，再开始重构，那么我们享受的好处会延迟，甚至可能会在一些没大有用的地方浪费精力。
产品工程师兼首席技术官Andreas Klinger是Fix-it Friday的粉丝，他表示：
“Fix-it Friday的规则很简单：除非当前的项目十万火急，否则周五的工作就应该是重构。让工程师选择他们的工作。我们不应该因为微观管理而抹杀这种乐趣。有些人会尝试新的库。有些人会修复积压的bug。这两种工作都很好。我们尝试鼓励大家平衡这些任务。”
无论采用哪种方法，你都需要慎重思考，询问团队哪些代码最影响他们的效率。
修复哪些代码对你的其他代码产生的影响最大？
解决哪些问题得到的回报最多？
你不太可能找到一整块专门的时间来重构代码，重构代码必然会牺牲你花费在其他项目上的时间，但请不要低估定期坚持开展小范围的重构带来的影响。聚沙成塔，集腋成裘，最终你会获得丰厚的回报。
文档与重构
标准化命名约定之类的文档可以让每个人都达成共识。Xerox的高级开发人员的研究发现，缺乏文档是重构最大的难题之一。
记录重构的工作内容不仅可以记录花费的时间，而且还可以为将来的团队成员提供说明。
最后，你还通过文档记录下自己的成功：重构带来的最大成功是什么？这些可以成为代码审核的考虑因素吗？
原文链接：https://medium.com/swlh/the-ultimate-engineers-guide-to-code-refactoring-c38372632906
近期热门文章推荐：
