技术债是什么
技术债是为短期交付选择权宜方案后需要偿还的额外成本。管理要点是让债务可见、可量化、有偿还计划，常见分类包括代码债、架构债、测试债、文档债与环境债。技术债不必然是错误决策：在抢占窗口期时有意欠债并在计划中安排偿还是合理做法。真正危险的是隐性债务——没人知道它存在，直到某次改动引发连锁问题。
基本信息
| 来源 | Ward Cunningham 1992 年以金融债隐喻提出 |
|---|---|
| 分类 | 代码债、架构债、测试债、文档债、环境债 |
| 管理方式 | 登记台账 + 定期评估 + 排期偿还 |
| 量化口径 | 改动风险、维护成本、事故关联度 |
| 偿还节奏 | 小步常态化，而非一次性大重构 |
| 触发条件 | 相关模块改动时一并处理 |
典型使用场景
- 需求排期：评估新功能所在模块的债务成本与风险
- 故障复盘：把反复出问题的模块列为偿债重点
- 新人上手：文档债与环境债直接影响新成员产出速度
- 架构演进：识别阻碍扩展的架构债，纳入技术规划
- 版本升级：依赖过期与运行时落后属于典型环境债
- 预算论证：用维护工时与事故成本折算偿还收益
技术债台账字段示例
技术债台账字段示例
名称：订单模块遗留存储过程
位置：order-db/stored_proc/*
影响：改动风险高、无单测覆盖
估计偿还成本：15 人日
触发条件：订单改版时一并处理
状态：已登记 / 评估中 / 已排期 / 已偿还债务类型与信号
| 类型 | 典型信号 | 偿还动作 |
|---|---|---|
| 代码债 | 重复逻辑、超长函数、命名混乱 | 小步重构并补测试 |
| 架构债 | 模块耦合、无法水平扩展 | 拆分边界、引入接口层 |
| 测试债 | 关键路径没有自动化覆盖 | 补核心用例并纳入门禁 |
| 文档债 | 部署与架构文档缺失 | 补齐并纳入变更流程 |
| 环境债 | 依赖版本过期、配置漂移 | 统一版本与配置管理 |
只登记不偿还的台账会变成摆设；把偿还项排进迭代与升级计划，债务管理才真正起作用。