技术债要按未来变化成本而不是代码新旧管理

技术债描述的是当前设计选择给未来修改、运行和验证带来的额外成本。有些债务来自为了时间主动取舍，有些来自需求变化、知识增长或外部依赖演进。旧代码不必然有债，新代码也可能在上线第一天就积累高利息。

把所有缺陷、重构愿望和待办统一叫技术债，会让清单失去决策价值。治理需要指出具体决策、受影响质量属性、触发条件和持续成本，再判断是偿还、控制还是接受。

债务本金与利息要落到可观察后果

“本金”可以理解为改变现状所需投入，“利息”则是维持现状反复付出的成本，例如每次发布都要人工修补、故障恢复更慢、功能跨越多个模块或安全补丁难以验证。利息若没有证据，只是对代码风格的不满。

有效条目应写清上下文：哪个架构决策造成什么约束，哪些场景会暴露风险，已有何种运行或交付证据。部署失败次数、变更前置时间、缺陷集中区域和依赖升级阻塞都可以作为依据，但指标与债务之间仍需解释因果链。

一次性缺陷通常进入缺陷管理；明确需求尚未实现属于产品工作；已知妥协导致未来变更更贵，才更符合技术债语义。分类不是为了争论名称，而是让责任、优先级和验收方式匹配问题性质。

架构债常跨越单个代码仓库

架构决策影响模块边界、数据所有权、部署拓扑和运行职责。共享数据库造成的跨服务联动、缺少版本化接口、不可替换的基础组件，都可能让局部改动牵动全局。仅重写一个类无法消除这类债务。

架构债还会与组织结构互相强化。没有明确所有者的共享模块长期得不到维护，多个团队绕过慢接口形成旁路，又进一步增加耦合。治理需要确定决策权和协作边界，而不是只分配编码任务。

外部条件变化也会生成债务。曾经合理的同步调用在流量增长后可能成为故障传播路径；受支持的组件进入停止维护阶段后，升级能力就成为风险。评审应允许重新评价历史决策，而不是把“当时正确”误解为永久正确。

风险主题比孤立清单更适合排序

SEI 的架构评估方法关注质量属性场景、风险、敏感点和权衡点。技术债条目也可围绕场景组织：在怎样的刺激和环境下，系统应达到什么响应，而当前设计在哪里增加失败概率或成本。

多个条目可能指向同一风险主题。例如缺少契约测试、手工发布和环境差异都增加发布失败风险。按主题聚合后，可以设计共同改进路线，而不是分别处理表面症状。

优先级应同时考虑风险暴露、利息增长、偿还成本、依赖关系和业务窗口。高成本不等于高优先，低成本也不代表现在就做。对很少变化且风险可接受的区域，记录并监控可能比重写更合理。

偿还可以是替换、隔离或降低利息

彻底替换只是策略之一。为旧组件增加稳定适配层，可以把变化隔离在边界；补充自动测试和可观测性，可以降低修改与恢复成本；限制新依赖进入旧模块，可以阻止债务扩散。这些措施不一定消除本金，却可能显著降低利息。

大规模重写风险高，因为现有系统包含未文档化行为。渐进迁移应定义可独立验证的阶段、双运行或回退路径，并明确何时删除旧路径。没有退出条件的兼容层会成为新的永久复杂度。

偿还工作要有业务可理解的结果，例如发布从每月一次变为每周可控、故障恢复不再依赖某位人员、依赖升级不再阻塞安全补丁。单纯统计删除代码行或提高测试覆盖率，不能证明风险已经下降。

决策记录保留债务形成与接受依据

架构决策记录应说明问题、约束、备选方案、选择理由和后果。若主动接受债务，还要记录到期条件、观察指标和责任人。未来团队由此能区分有意识取舍与无意遗漏，也能在条件变化时重新打开决策。

记录不应成为审批负担。对影响边界、数据、可靠性或安全的决定保留简洁证据，比为每个代码变化写长文更有效。状态可以是提议、已接受、已替代，并链接到实现和验证结果。

到期日期本身不会让债务自动优先。更实用的是触发条件，例如日流量达到某值、第三个消费者接入、恢复时间超过目标或上游版本停止支持。条件出现后，预先约定的评审才能及时启动。

治理要防止清单膨胀和指标游戏

定期盘点应合并重复条目、关闭已失效问题，并检查高风险债务是否仍有控制措施。没有所有者、证据和下一次评审条件的条目，不应长期占据优先队列。

技术债数量不是绩效指标。团队可能通过拆分或合并条目改变数字，也可能为了“清零”进行低价值重构。应关注关键风险主题的暴露是否下降、变化成本是否改善，以及新决策是否在可接受范围内。

治理还要给主动取舍留空间。为了验证市场或应对紧急事件，可以接受局部债务，前提是边界清楚、可回滚、不会触碰不可恢复的数据与安全底线，并保留后续证据。

技术债管理最终是架构演进管理。它把未来变化成本从模糊抱怨转化为可审查决策，让团队知道哪些妥协正在付息、何时需要行动，以及怎样用最小风险改变系统。

资料依据

• Carnegie Mellon Software Engineering Institute：Software Architecture，https://www.sei.cmu.edu/software-architecture/
• Carnegie Mellon Software Engineering Institute：Architecture Tradeoff Analysis Method Collection，https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/