遗留代码开发：为何过去不会消失，以及应对之道
人工智能已成为软件开发领域的热门话题。每周都有新的 AI 代码助手、自动化测试生成器和重构工具问世，每一款都承诺更快、更智能的开发，而其中许多工具产出的海量代码，将成为下一代的遗留代码。
然而，无论是在工程师会议还是董事会上，总有一个事实被反复提及。
当今运行世界的大多数软件在编写时并未考虑 AI，大规模替换它们既不现实，也难以负担。妥善管理而非替换这些软件，将是未来十年工程师团队面临的最具战略意义的挑战之一。
什么是遗留代码
"遗留代码"听起来像是"陈旧且有缺陷"的委婉说法，但这一术语涵盖的范围远不止于此。
它指的是在现行标准、架构或工具出现之前构建的任何代码库，企业对其持续维护和扩展，而非重写。这些代码库通常规模庞大，且往往对业务运营至关重要。
几个例子：
比起代码的年龄，更关键的是几个往往同时出现的特征。
遗留代码常见的五大特征
这些特征很少单独出现，而是相互叠加，这也是遗留系统运行越久越难以变更的原因。
1. 技术债务
技术债务源于代码捷径、临时方案和迫于工期的决策不断累积。每一项都解决了眼前的问题，但代价会在日后显现：代码变得比原本更难修改。
2. 测试覆盖率不足
测试覆盖率不足，因为很多代码都是在自动化测试成为标准实践之前编写的。如果没有测试来捕捉回归问题，每一次变更都可能破坏那些无人记录、也无人可快速验证的行为。
这些系统经过了实际使用的验证，有时关乎生命安全。系统一旦出现故障，可能引发灾难性的下游后果。
3. 架构漂移
随着多年的不断扩展，架构逐渐偏离最初的设计，最终代码中不再体现其预期的结构。最初清晰的模块边界逐渐模糊，代码库反映的更多是补丁的历史，而非最初的设计意图。
这些遗留系统（有些设计于数十年前）所面向的现实环境已经发生变化。因此，过去的架构决策同样值得认真重新审视。
4. 知识流失
最了解系统的工程师离开时，知识也随之流失。决策背后的考量，以及有人曾手工处理过的边界情况，往往没有文档记录。每一次人员离职，都会让系统更难以安全地变更。
5. 高耦合、低内聚
高耦合与低内聚使模块之间紧密绑定，每一次变更都变得风险高、成本高。在某处所做的修复可能波及系统中不相关的部分，因此即使是很小的改动，也可能需要大范围测试。
Michael Feathers 在其著作 Working Effectively with Legacy Code 中给出了最简洁的定义：遗留代码就是没有测试的代码。按此标准，全球在役生产软件中有相当大的一部分都属于遗留代码。
AI 并非从零开始
人们很容易把 AI 工具视为从头再来的契机：编写全新的 AI 辅助代码，将其部署到云端系统和现场设备，快速推进。
这听上去合乎逻辑，但行业数据讲述的是另一番景象。
在 2025 年技术与安全预测中，Forrester 预计到 2026 年，75% 的技术决策者将面临技术债务上升至中度或高度严重级别的局面，并将这一上升归因于 AI 的快速发展使 IT 环境更加复杂。
Deloitte 2026 年全球技术领导力研究估计，技术债务占企业 IT 总支出的 21% 至 40%。这部分支出用于维持旧代码运转，而非交付新价值。
综合来看，这些数据指向一个简单的结论：AI 时代的软件开发不是从白纸开始，而是建立在企业每天依赖、无法停用的存量系统之上。
透析机的控制软件无法在患者当下依赖它的同时从头重新设计，车辆的嵌入式安全系统也不能为一次耗时数年的重写而暂停。
遗留代码将始终存在，因为现实世界的软件运行在现实世界的约束之上。
遗留代码为何难以借助 AI
要让遗留代码为 AI 做好准备，首先要理解它为何本就难以借助 AI。
AI 编码工具从模式中学习，在一致、结构良好、文档清晰且架构连贯的代码上表现最佳。AI 在较小范围内学习效果最好，在大规模场景下则需要语义层面的引导。
遗留代码库往往同时缺乏这四项特质，具体表现为三个反复出现的问题。
1. AI 看不到它无法理解的内容
缺乏文档的代码、埋藏在数十年前逻辑中的隐含假设，以及缺失或过时的注释，都会使 AI 的建议变得不可靠。
AI助手可能提出一个表面上整洁的重构方案，却悄然破坏了某个从未有人记录的约束。
2. 架构侵蚀掩盖了真实结构
遗留系统常常遭受所谓的软件侵蚀：系统预期的架构与最终实际形成的架构之间逐渐出现偏差。
AI 工具无从得知原始设计的意图，只能基于眼前的代码工作。
3. AI 可能加速错误的方向
第三个问题会加剧前两个问题。如果缺乏规范地使用 AI 代码生成，它可能增加技术债务，而不是削减技术债务。
AI 工具的优化目标是生成能够编译并通过基础测试的代码，并不内置对长期可维护性或架构完整性的考量。当这类代码在缺少质量把关的情况下进入遗留代码库，可能让底层问题比原先更加严重。
让遗留代码为 AI 做好准备
应对这些问题最常见的做法，要么无视遗留代码、任其滑向危机，要么尝试成本高昂的重写，二者都不奏效。
更务实的方法是投资代码质量工具。这类工具基于四项能力构建，可让遗留系统逐步变得可理解、可度量、可改进。
🎥 观看专家小组讨论回放："Maximize the potential of AI in Quality Assurance"（最大化 AI 在质量保证中的潜力） 🎥
1. 可见性
任何改进工作都基于对代码库的准确认知，包括：
- 架构违规
- 技术债务在架构中的集中位置
- 循环复杂度最高的具体模块
- 死代码残留的位置，以及哪些克隆代码簇重复了逻辑
缺少这些量化的分析数据，团队只能盲目工作，不知道该聚焦何处、该重构什么、该保持什么稳定。
2. 架构恢复
对许多遗留系统而言，原始架构文档要么已经丢失、过时，要么从一开始就不完整。
架构验证工具通过从代码本身逆向还原实际结构来填补这一空白，并揭示隐藏的耦合、边界违规和未记录的依赖关系。
一旦掌握真实架构，团队就可以对其建模、治理和保护，对每次新提交自动对照该模型进行检查。
3. 差异分析
试图一次性修复软件中的所有问题，无异于同时做所有的事，往往会导致停滞不前。
差异分析以现有问题为基线，确保新增或修改的代码不再引入新的违规，从而避免这种局面。它让 AI 能够有针对性地检查自身的编码活动，而不被不相关的问题干扰。这种"冻结并改进"的方法，既正视并管理遗留债务，又从第一天起就对新工作保持高标准。
当 AI 生成的代码进入遗留代码库时，它尤为重要：在任何内容合并之前，标记 AI 的建议是否符合项目的编码标准和架构约束。
4. 持续、自动化的监控
改进遗留代码是一项持续的工作，因此质量检查应纳入 CI/CD 流水线。每次变更都会被自动分析，指标随时间持续追踪，当代码库开始向错误方向漂移时，团队能获得早期预警。
这种持续监控也是让遗留代码库为 AI 做好准备的关键。一致且治理良好的代码，为 AI 助手提供了坚实的工作基础，也让团队有信心确保 AI 生成的建议经过验证，而非被盲目采纳。
让遗留代码重回掌控
静态代码分析在不运行源代码的情况下对其进行检查，标记缺陷、风格违规、安全漏洞及其他质量问题。
对遗留代码库而言，这往往为团队提供了第一份量化的代码质量全貌，同时也为这类项目所依赖的差异分析提供支撑。
登士柏西诺德（Dentsply Sirona）和费森尤斯医疗的团队已使用该技术，将冻结的遗留代码与活跃开发分开管理，在以可控节奏处理遗留部分的同时，保持新代码的整洁。
在系统演进中验证架构
在遗留代码中，此类架构验证会提取实际的软件结构，并与系统本应具备的设计进行比较。这样，隐藏的耦合、违规依赖和边界违规就能被看见并持续监控，它们正是让人不敢轻易改动遗留代码的原因。
随着 AI 工具生成的已提交代码占比不断提高，流水线中的自动化架构与质量验证，将成为保障 AI 辅助开发可持续的安全网。
🎥 视频回放："Axivion Suite - ROI of Static Code Analysis and Software Architecture Verification"（静态代码分析与软件架构验证的投资回报） 🎥
认为 AI 会让遗留代码变得无关紧要，是对软件系统运作方式的误解。
大型、复杂、安全关键和业务关键的系统会不断积累历史，而遗留代码中的这些历史蕴含着真实价值，包括业务逻辑、领域知识、法规合规性，以及多年积累的运行可靠性。
不加评估就丢弃或替换将带来风险。
能够、也必须改变的，是工程团队对待遗留代码的方式。
与其把它当作不可触碰的黑盒或耻辱之源，团队应系统地度量和理解遗留代码，在其演进过程中保护其架构完整性。
遗留编程是软件开发 AI 时代的基石，而真正的问题是：这些遗留代码究竟是被理解、治理和维护，还是任由风险累积直至失效。
⚠️将代码质量投入视为风险管理，而非额外开销。
