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