业务应用中的技术债务：如何衡量、排定优先级并逐步偿还

几乎每一个运行了几年的业务应用都会出现相同的症状。以前一周就能完成的小功能，现在要一个月。每次发布都会在没人动过的地方冒出缺陷。新开发人员需要很长时间才能看懂代码，老开发人员则不敢修改某些模块，生怕牵一发而动全身。企业主看到开发成本不断上升，产出却越来越慢。

这些症状几乎都源于技术债务：在设计、代码、测试和基础设施上所做的妥协随时间不断累积。本文用商业语言解释什么是技术债务、它有哪些类型、如何衡量、如何决定优先偿还哪些，以及如何在管理层和技术团队之间建立健康的预算机制与沟通方式。

要点摘要

• 技术债务是今天走捷径在未来带来的额外成本；和财务债务一样，它有本金也有利息
• 并非所有技术债务都是坏事；危险的是那些没人察觉、没有记录、从未偿还的债务
• 用业务能理解的指标衡量其影响：发布速度、变更失败率、恢复时间和修复缺陷的工作量
• 按照代码区域的修改频率和风险大小来排定优先级，而不是看代码有多难看
• 预留固定的产能来分期偿还债务，例如每个工作周期的一部分时间，而不是等待一次大规模重写

用商业语言理解技术债务

设想团队为了赶上发布选择了捷径：复制代码而不是做成可复用的组件，跳过自动化测试，或者用不太合适的结构存储数据。这样的决定完全可能是合理的，按时上线也许比完美的代码更有价值。但从那以后，这个区域的每一次修改都会更贵一点。这部分额外成本就是技术债务的利息。

本金则是修正这些妥协所需的工作。只要本金没有偿还，利息就会以更长的开发时间、更频繁的缺陷和更高的事故风险持续支付。如果债务不断堆积，总有一天利息会耗尽团队几乎全部的产能，企业就会感觉应用已经停止进化。

技术债务的类型

技术债务不只是代码凌乱。了解它的类型，有助于管理层看清真正的问题在哪里。

• 代码债务：重复代码、过长的函数、含糊的命名，以及分散在多处的业务逻辑
• 架构债务：模块边界模糊、依赖关系相互缠绕，或者结构已不再适应业务规模
• 测试债务：没有自动化测试，每次修改都只能手工测试，否则就可能破坏其他功能
• 基础设施债务：服务器、操作系统和编程语言版本已不再受支持，发布流程依赖手工操作
• 依赖债务：过时且存在安全风险的第三方库
• 数据债务：数据库结构不一致、数据重复、缺少校验规则
• 文档与知识债务：系统如何运作只有一两个人知道

依赖债务常被低估，因为在出现安全漏洞之前它一直是隐形的。更详细的讨论见 依赖安全与软件供应链。测试债务则可以通过逐步建立 自动化测试与 CI/CD 来偿还，先从对收入最关键的流程做起。

技术债务从何而来

来源多种多样，并不总是因为开发人员技术不够。过紧的工期、中途变化的需求、供应商或团队成员的更替，以及超出原始设计的业务增长，都会增加债务。例如，一个为单一门店设计的应用，在企业发展到二十家门店时就会显得捉襟见肘，即使它的代码在当时写得很好。

AI 辅助开发的趋势也改变了这一局面。AI 助手可以更快地生成代码，但如果缺乏严格的评审，它同样会加速重复代码和不一致模式的累积。相关的质量控制，请参阅 AI 辅助软件开发。

如何衡量技术债务

技术债务很难直接用金额衡量，但它的影响是可以观察到的。把速度、稳定性和工作量指标结合起来，管理层就能获得客观的全貌。

速度与稳定性指标

• 从功能获批到在生产环境上线所需的时间
• 发布频率：能够安全交付变更的频率
• 变更失败率：引发严重缺陷或必须回滚的发布所占比例
• 恢复时间：发生事故时团队恢复服务所需的时间

这四项指标在软件行业广为人知，业务人员也比较容易理解。如果功能交付时间持续拉长、失败率不断上升，就强烈表明技术债务的利息正在膨胀。来自 可观测性与日志系统 的事故和错误数据，可以帮助补全这幅图景。

工作量指标

记录团队产能中有多大比例用于修复缺陷、处理事故和手工例行工作，又有多少用于开发新功能。如果团队一半以上的时间都在救火，企业实际上是在支付利息而不是投资。再加上定性观察：开发人员最害怕哪些模块，哪些部分只有一个人懂。

排定优先级：并非所有债务都要偿还

常见的错误是试图修复所有难看的代码。然而，那些很少被修改、也没有风险的难看代码几乎不会产生利息。优先级应沿两个维度确定：该区域被修改的频率，以及出问题时影响有多大。

1. 01修改频繁且影响大的区域，例如结账、价格计算或薪资：优先偿还
2. 02很少修改但影响大的区域，例如安全模块或支付集成：用测试和监控加以保护
3. 03修改频繁但影响小的区域：每次接触时顺手整理一点
4. 04很少修改且影响小的区域：保持原样，记录在案即可

与安全和合规相关的债务，例如已不再获得安全更新的软件版本，应当作为单独的优先事项处理，因为其风险不只是变慢，还可能是数据泄露或受到处罚。

偿还技术债务的策略

定期分期偿还

最健康的做法是在每个工作周期中预留固定比例的产能来偿还债务，例如每个迭代的一小部分时间。定期偿还可以防止债务堆积，也不需要每次都做重大的预算决策。再配合一个简单原则：每当团队为新功能接触某个区域时，都让它比之前更整洁一点。

有针对性的修复

对于大额债务，例如过时的框架版本或脆弱的核心模块，应规划一个目标和成功标准都很明确的修复项目。先用测试加以保护，再一点一点地修改，并分阶段发布。这种渐进方式也在 不中断业务的遗留系统现代化 中有所讨论。

何时从零重写

重写整个应用听起来常常很诱人，但风险很高：成本大、周期长，而且在此期间企业必须同时维护两套系统。只有当底层技术确实无法维持，或者业务需求已变化到旧设计完全不再适用时，重写才值得考虑。即便如此，逐个模块替换通常也比一次性大规模上线更安全。相关的架构决策，例如把应用拆分为独立服务，请参阅 单体还是微服务。

与管理层沟通技术债务

技术团队往往很难争取到偿还债务的时间，因为管理层只看到功能清单。反过来，管理层也很难评估用技术术语描述的修复请求。桥梁在于影响的语言：不要说某某模块的代码很乱，而要说每次调整价格都要两周，而且经常算错，这项修复预计能把时间缩短到三天。

建立一份所有人都能看到的技术债务清单，写明简要描述、业务影响、预估工作量和优先级。在规划功能时一并审视这份清单，让增加或偿还债务的决定都是有意识做出的。对于由供应商维护的应用，应把技术债务报告和修复时间比例写进 上线后的应用维护 合同中。

常见错误

• 把技术债务视为纯粹的技术团队问题，而它其实直接影响业务的速度和成本
• 把所有修复都推迟到一个永远不会真正启动的重写项目
• 修复难看但不重要的代码，却放任关键区域不管
• 不记录所走的捷径，导致债务一直隐形，直到演变成危机
• 只按功能数量衡量团队绩效，使团队缺乏维护质量的动力

常见问题

用多少时间偿还技术债务比较合理？没有固定数字。许多团队从每个周期一小部分稳定的比例开始，再根据速度和稳定性指标进行调整。如果指标持续恶化，就需要暂时提高这一比例。

如何了解前任供应商开发的应用中有哪些技术债务？先请独立方对代码和基础设施进行审计：技术版本、测试覆盖率、数据库结构、依赖安全和文档。这一步在 更换供应商或挽救停滞项目 之前同样重要。

应用变慢一定是技术债务造成的吗？不一定。有时原因是数据量增长或基础设施不足。诊断方法请参阅 数据库性能与变慢的业务应用。

技术债务能降到零吗？实际上不能，这也不是目标。目标是把债务保持在已知且可控的水平，让利息不会拖累业务。

结论

技术债务是软件开发中的正常现象，正如负债是企业融资中的正常现象。问题出在债务隐形、未被衡量且从不偿还的时候。借助共同认可的指标、基于修改频率和影响的优先级、每个工作周期的定期偿还，以及用商业语言进行的沟通，企业可以让自己的应用多年来始终保持开发迅速、运行安全。