如何处理遗留的代码-爱代码爱编程

对于软件顾问或软件工程师来说，他们花了很多时间来处理遗留的代码，要么为新的商业用例增强它，要么重构原始代码，使其适合新的用途。只有一些事情是奇妙的绿地项目，你可以从头开始写一个完整的系统。

分析软件环境
就像你如何评估一项新任务的需求一样，这个特别的分析需要关注整个系统的情况。这意味着代码库，它的测试，代码的部署和任何依赖你正在工作的代码库的下游服务。几个很好的起始问题是：

这段代码应该做什么？它实际上做了什么？代码实现其目标的情况如何？
当前代码库的文档化和测试情况如何？
代码库的更新频率如何？
这些问题将引导你找到最紧迫的问题所在。例如，如果代码是经常更新的，因为它是一个monorepo或核心服务，那么部署过程是怎样的？在这个领域很可能会有很容易的改进，以实现更快和更高的交付质量。

有很多工具可以帮助进行代码分析和识别代码覆盖/代码气味，以便对你所处理的代码质量和复杂性有一个更坚实的概念。这些工具应该与从事代码库工作的工程师以及利益相关者一起使用，以了解哪些地方拖累了团队，业务逻辑应该是什么，以及你正在审查的特定服务的业务重点在哪里。

提高代码库的可维护性和可读性是很好的，但如果对系统的性能有负面影响，那就不行。因此，要时刻注意衡量系统的指标，例如：响应时间、用户注册量、获取新用户的时间等等。

制定一个行动计划
一旦你分析了代码库并获得了足够的信息，是时候制定一个行动计划了。你将如何处理这个代码库？哪些是需要改进的关键领域？

根据项目的范围和预算，可以使用各种方法和途径。两种常见的方法是在遗留代码前创建一个门面层，简化与遗留代码的交互，只暴露关键功能。门面层将从头开始构建，所以你可以遵循一个简单的设计模式来保持事情的可扩展性和可维护性。

另一种常见的方法是用新的服务逐步取代部分遗留代码，使旧的代码与新的代码保持一致，直到完全取代。新的服务将是你架构好软件的机会，也将从头开始构建，如果你选择这样做，你可以使用设计模式。

选择一个设计模式
设计模式是对软件设计中经常出现的问题的典型解决方案。它们就像预先制作好的蓝图，你可以通过定制来解决你代码中反复出现的设计问题。

如果它适合你的用例，或者你的目标是简单地改进当前的遗留代码库，那么就挑选一个适合你的要求的软件设计模式。选择设计模式的一个好的指导方针是使系统更容易测试。

外面有大量的设计模式，所以考虑一些因素，如权衡，使用的编程语言/框架和抽象水平将有助于你的决定。

测试、验证和审查
你需要的最后一件事是测试、验证，然后审查所做的修改。你需要确保你所创建的软件是适合的，并以你认为的方式工作。除了单元测试，在你的服务和代码库周围添加一大堆集成和回归测试，将有助于确保没有错误被引入到系统的其他部分，而你还没有触及，以及验证事情仍然顺利地工作。

记录你的代码和它的变化是关键，以提供你的代码库的可见性，而不需要有人去阅读每一行代码来理解你的系统。一旦到了这个阶段，回过头来检查你所做的改变，以及是否需要重申以改善系统和代码库，这是一个好的点。

结论和启示
正如你可能知道的那样，处理遗留代码并没有一个 "一刀切 "的方法。我想提供的主要启示是：

迎合你的用例。通过系统的映射，找到你的具体痛点，不仅可以帮助其他工程师，也可以帮助项目经理接受你提出的方法。

确保你有方法来衡量系统性能和重构的关键业务指标。

保持可维护性在你脑海中的位置。你很可能会发现系统的某些部分没有记录，在这种情况下，为该服务/组件创建一个README或运行手册，将有助于其他工程师在维护或未来的代码修改中。

应该始终考虑的是，要注意范围蠕变的问题。让一个系统容易扩展是很好的，但如果没有计划在不久的将来实际使用你的可扩展代码，这样做就会带来额外的时间和复杂性。