目录

• 哪些是遗留代码
• 解决遗留代码的方式
• 单元测试常见的误区
• 选择性单元测试
  • 遗留代码单元测试的成本收益象限分类
    • 分类标准
    • 四个象限二维表
    • 圈复杂度与依赖的概念理解
  • 不同类型代码的处理策略
• 建议

文章介绍了遗留代码的概念，并对遗留代码进行了分类。针对不同类型的遗留代码，提供了相应的处理策略。

哪些是遗留代码

• 1、与过时技术相关的代码：

  • 与不再受支持的操作系统或软件库相关的代码。
  • 依赖于已淘汰的技术栈或编程语言的代码。

• 2、为兼容老旧功能而保留的代码：

  • 在现代软件中为了兼容旧版本功能而保留的代码片段。
  • 为了确保向后兼容性而不得不保留的代码。

• 3、缺乏文档和维护的代码：

  • 没有良好文档支持的旧代码。
  • 缺乏现代开发实践（如单元测试、代码审查等）的代码。

解决遗留代码的方式

解决遗留代码有以下三种常见的处理方法及其利弊：

• 1、推翻重来。

  成本高，系统正在运行，会带来代码风险。

• 2、代码重构。

  成本高，系统正在运行，会带来代码风险。

• 4、补充单元测试。

  通过单元测试识别现有代码中的问题，为未来可能的代码变更提供质量保障。

  根据上述描述，补充单元测试是一种有效解决遗留代码问题的方法。然而，这种方法仍然存在一些问题：

  • 大量遗留代码缺少单元测试，并且由于代码间的复杂依赖关系，进行测试的成本非常高。

  • 具体的衡量标准却不够清晰，无法定义好的单元测试。

  • 哪些代码需要添加单元测试？

单元测试常见的误区

• 1、缺乏断言的假单元测试。

  开发者可能会采取仅调用函数而不进行断言的方式，以提高覆盖率指标，导致了许多无效的单元测试。

• 2、把单元测试当成白盒测试。

  一些观点将单元测试归类为白盒测试，但实际上应将其视为针对函数签名的黑盒测试。

• 3、依赖真实环境的单元测试。

  阻碍单元测试的主要因素包括惰性和依赖环境配置。

  若不使用 Stub 或 Mock 解除对外部环境（如网络 IP、数据库）的依赖，单元测试将难以达到 快速、独立、可重复、自我验证、及时性的原则。

选择性单元测试

单元测试除了带来收益外，本身也会产生一定的成本。

如果从收益与成本的角度分析遗留代码，将有助于明确为遗留代码补充单元测试的策略，即选择性单元测试。如何界定成本与收益呢？

遗留代码单元测试的成本收益象限分类

针对遗留代码的单元测试，可以根据其成本和收益进行象限分类。根据下图，对分类标准和各象限进行详细说明：

分类标准

• X 轴（成本）：代码依赖程度越高，测试成本越大。
• Y 轴（收益）：代码复杂度越高，质量收益越大。

四个象限二维表

圈复杂度与依赖的概念理解

• 圈复杂度（Cyclomatic Complexity）：衡量代码中逻辑分支的数量。
• 扇入（Fan-In）：直接调用该模块的上级模块的个数，扇入大表示模块的复用程度高。
• 扇出（Fan-out）：一个模块直接调用的其他模块的数量，扇出大表示该模块依赖其他模块越多。

不同类型代码的处理策略

根据以上分析，遗留代码的处理策略就变得明确。

• 1、算法类代码（Algorithms Code）：生成单元测试。
• 2、协调类代码（Coordinators Code）：进行集成、接口测试。
• 3、复杂代码（Overcomplicated Code）：寻找合适的机会进行重构。
• 4、琐碎代码（Trivial Code）：不做处理。

建议

虽然 AI 时代 AI 帮助开发者们解决遗留代码的问题，但仍然需要开发者们根据实际情况，进行有效的评估和决策。

针对复杂遗留代码的优化，并不建议开发者们盲目进行全面的优化和重构。遗留代码的变更可能会带来巨大的风险。因此，开发者应根据具体情况，在合适的机会，遵守童子军法则，进行重构和优化。在这一过程中，通义灵码也将为您提供有力支持。

以上便是在处理遗留代码时可参考的实践。处理遗留代码需要深入代码的复杂结构，细致地追踪每一个可能的分支节点。在这一过程中，除了识别并修复潜在的缺陷外，还必须在有限的时间内完成所有任务。为了避免这一局面的发生，最佳的策略是预防代码的腐化，善用工具，并在编写初期遵循良好的编程原则。

9ong@TsingChan 文章内容由 AI 生成。