遗留代码重构：技巧、步骤和最佳实践

在软件工程学里，重构代码一词通常是指在不改变代码的外部行为情况下而修改源代码，有时非正式地称为“清理干净”。在极限编程或其他敏捷方法学中，重构常常是软件开发循环的一部分：开发者轮流增加新的测试和功能，并重构代码来增进内部的清晰性和一致性。自动化的单元测试保证了重构不至于让代码停止工作。

重构既不修正错误，又不增加新的功能性。反而它是用于提高代码的可读性或者改变代码内部结构与设计，并且删除死码，使其在将来更容易被维护。重构代码可以是结构层面抑或是语意层面，不同的重构手段施行时，可能是结构的调整或是语意的转换，但前提是不影响代码在转换前后的行为。特别是，在现有的程序的结构下，给一个程序增加一个新的行为可能会非常困难，因此开发人员可能先重构这部分代码，使加入新的行为变得容易。

一个重构的小范例是修改一个变量的名称使其具有更明确的含义，例如从单个字母的“i”重构为“interestRate”（利率）。较复杂的重构是把一段if区块中的代码变为一个子程序。更复杂一点的重构是用多态性来替换if 条件式。进一步还可重新设计运作的算法。“清理”代码已经发生了几十年，重构中最关键的认知是有意地“清理”代码，透过从已知的纪录里一些常用的重构方法清理代码，把它从增加新功能分开，然后个别的对代码进行测试（任何的行为改变都可能带来错误）。新的实现切合实际需要以改善现有设计，并且不改变原软件的意图或行为。

重构面对业界调适接受方面的挑战。首先，对重构长远的影响需要更深入研究追踪。再者，重构存于资料库轮廓（database schema）的商业逻辑层几乎是不可能或者非常困难的。最后，对接口造成影响的重构可能造成程序开发上的困境，除非程序员有对所有用户界面的访问权。例如，程序员若改变某实体中的方法名称，他或她不然要对整个专案里头所有链接到旧名的参考都加以编辑，不然就只能继续维护使用旧名的残株残瓦接口。而该旧名的接口于内部调用该方法的新名。

没有人喜欢处理遗留代码，因为它可能是一项令人困惑的工作；充其量，这很费时间。但是，我们现在是否要忍受保留和使用遗留代码的巨大影响和成本？

遗留代码通常总是与技术债务相关——实现快速发布和最佳上市速度的成本；然而，以提供高质量和持久的代码为代价，这些代码仍然需要在以后进行修改。根据Hitachi 咨询研究，遗留系统阻碍了至少 90% 的组织的效率。

毫无疑问，遗留代码正逐渐成为企业的沉重负担。IT 软件质量联盟最近的一项调查显示，遗留系统在 2018 年给美国公司造成了超过 5000 亿美元的损失，随后几年的数字更高。

虽然我们可能无法衡量个别公司与遗留代码相关的技术债务和相应成本，但相关的问题是，可以做些什么来避免它们？

没有快速简便的方法来解决问题，但遗留代码重构是改造旧的和以前的软件系统并优化其功能的有效方法。

重构是简化或修复有问题的遗留代码的方法之一，而不必更改代码的结构或体系结构。问题是大多数公司错误地理解了重构的概念，尤其是重构遗留代码的过程。

什么是重构遗留代码？

代码重构是一种纠正过程，它需要修改和重新安排以前编写的软件程序，使它们更容易理解、维护和更有效，而不会改变或危害程序的功能。

在遗留代码中实施重构的最终目标是优化代码并提高其性能，但不改变其操作。在重构过程之后，最终版本变得更易于解释、管理和更新。

重要的是，只有了解代码的限制、用途和预期的可操作性，才能实施重构。之后，代码被逐段测试和返工。测试和重构遗留代码并不相互排斥，因为如果不对各种模块和组件进行单元测试，就无法进行完整而有效的重构。

许多公司和开发人员犯了在没有进行相应测试的情况下执行或使用遗留代码的错误。重构后，开发人员应对程序进行测试以确保没有缺陷。

正如引言中所强调的，在没有首先重构或修复的情况下执行遗留代码只会是一场等待发生的灾难。

一个很好的例子是2017 年流行的 Equifax安全漏洞，其数据库遭到破坏，网络犯罪分子可以访问大约 1.5 亿人的个人信息。

根据专家的说法，这是一次本不该发生的网络攻击。美国政府问责局的报告解释称，此次违规主要是 Equifax 网站遗留代码的直接后果。该公司后来将花费超过 10 亿美元来解决违规的影响。

遗留代码之所以成为问题，主要是因为脏代码、代码腐烂、损坏的代码或仅仅是过时的代码。而且，在解决这个问题时，重构并不是唯一可以使用的方法。一些专家反对重构，只会建议重写代码。

我们不会关注重写与重构的争论。不可否认，它们都是达到相同目的的不同手段。但是，重要的是要了解每个概念的好处以及何时最好应用重构或重写。

遗留代码重构与代码重写

在某些情况下，增量更改和连续迭代可以完成工作，而在其他时候，只需要从头开始即可获得所需的结果。知道什么时候应该重构或重写很重要。这将帮助你节省时间和资源。

没有指定和明确的规则来决定何时应该选择重写或重构程序。在做出决定之前，你可能需要考虑许多因素，包括时间、可用的专业知识、需求等。但根据最佳实践，我们将重点介绍一些可以轻松做出决定的指导方针。

什么时候应该选择重写

重写是开发人员丢弃所有现有代码并开始新的编程过程的过程。在这里，整个代码被重组和重做以反映初始功能并可能添加更新的功能。以下是应该考虑重写的原因：

当有重大转变时：如果正在架构中进行任何重大转变，例如从整体迁移到微服务或将 angular js 迁移到angular ，则应该考虑重写。在这里，旧程序的每个元素都可以从头开始重新创建。

当大部分代码脏了或无法运行时：有时，整个代码或代码的主要部分完全脏了且无法运行。在这种情况下，开始重构是浪费时间；最好的解决方案是重写。一些专家提出了 80% 规则——如果 80% 的代码需要修改，你就应该重写它。

当 框架 无法再维护时：为什么要尝试修复一些实际上无法维护或变得过于复杂和昂贵而无法维护的东西？如果无法维护代码，只需重新构建它。

当团队无法解释代码时：如果团队无法解释以前的程序，就该重写它了。

重写的优点：

该程序将具有更新和最近的功能。

重写会给程序带来新的外观和设计。

不断迭代。

有机会改正以前的错误。

重写的缺点：

重写往往会消耗更多时间。

你会花费更多的资源，包括金钱。

面临丢失以前功能的风险。

它可能需要新的专业知识或学习一门新语言。

何时应该选择遗留代码重构

以下是应该重构遗留代码的原因：

如果不能停止连续性：有时，重写可能意味着您必须关闭操作，这对业务运营是不利的。因此，与其关闭商店并让客户等待，不如实施渐进式重构。

当你需要使代码更具可读性时：有时，软件开发需要很长时间（可能是数年）才能完成，这可能意味着另一组工程师可能会完成该项目。或者，可能只是创建该程序的开发人员已经离开了。在这种情况下，重构是必要的，以便新工程师能够理解、解释和维护程序。

监管要求：某些监管标准和政策可能会要求您升级你的系统。

系统需要新功能：添加新功能（例如语言或错误修复）通常需要重构过程，技术更新对你的程序至关重要，因为它们可确保最佳可靠性。

扩展的需求是必不可少的：假设产品正常运行，但添加新功能的时间太长，或者由于升级而导致一系列问题，那么你绝对应该重构。

安全风险：遗留程序面临妥协和安全漏洞的风险。因此，为了防止黑客攻击的发生，应该重构并定期更新。

重构的优点：

代码变得更有条理且易于理解。

仔细重构遗留代码可在不改变其功能的情况下增强程序的操作和性能。

它有助于发现错误并清理污垢和腐烂物。

节省时间和资源。

该程序变得更易于维护和扩展。

重构的缺点：

你最终可能会改变代码的性能和功能。

它可能比你想象的花费更多的时间。

你面临着使代码复杂化而不是简化它们的风险。

重构遗留代码库的简单步骤

重构遗留代码是一项相当令人不愉快的任务，大多数人倾向于避免它，因为他们认为这不容易执行。但是，因为你不喜欢重构而丢弃有用的遗留代码将是一种浪费。按原样实施遗留代码风险太大，因为它会损害产品的可操作性和安全架构。

那么，重构遗留代码的方法是什么？我们将概述以下步骤，以了解如何开始重构遗留代码。

1.分解整个过程

当浏览模块时，首先映入你脑海的是如何开始以及从哪里开始。不要直接跳进去；你会不知所措和困惑。细分为微小的相关位。这样做将帮助轻松识别更改点。

这个阶段还需要将庞大的或单一的类分解成更小的组。分离每个整体类后，你可以创建新文件并按照 Java 模式重命名所有变量。

2.识别并删除依赖项

在获得对代码的访问权限后，接下来就是识别和删除依赖项；这样做不仅使程序可读。当依赖关系被分离和移除时，编写测试变得更容易。

3.探测变量和运行测试

你可以采用各种方法来测试代码，但是你必须要有测试脚本；否则无法探查。在测试期间，设置数据点并比较结果。如果有更多可访问的访问点可用，编写测试会更容易。

4. 确定并实施适当的架构

在先前阶段收集的信息将提供对最适合项目的架构类型的充分洞察。此外，前面练习中生成的较小组件在实现架构时会很有帮助。

遗留代码重构的技巧和基本原则

将程序分解成更小的相关子句。

一步一个脚印。

确定更改区域并将它们写下来。

创建一个时间表并坚持下去。

使用测试用例。

在适用的情况下自动化重构过程。

分析并比较结果。

再次测试。

遗留代码重构最佳实践

重构说起来容易做起来难；这是一件敏感的事情，如果处理不当，可能会导致更多的问题。不要忘记：目标是在不改变其功能的情况下优化程序。

以下是完成工作的一些建议：

为必要的实施做准备

你可能有一些云迁移问题要问。迁移的理想起点是评估程序环境并评估其功能以设计升级策略。为库和其他应用程序设置做备份。

小步快跑

应该一点一点地重构你的代码。对你的程序进行细微调整；每个微小的差异都会稍微改进你的程序并保持应用程序的功能。

运行测试

重构操作应伴随相关测试，以确保更改有效且无错误。

重构不应该引入新特性

重构不应改变程序的操作或功能。相反，它使它变得更好、更快、增加了可用性并使程序更有效率。

结论

应定期更新遗留程序和功能应用程序。遗留系统升级会导致性能提高、进展更容易、持续开发和改进的用户体验，但缺乏更新会导致安全漏洞。