技术债务是为了短期利益而采取的次优技术决策所累积的额外维护成本。
技术债务 = 快速交付的收益 - 长期维护的额外成本
| 类型 | 说明 | 示例 |
|---|
| 有意债务 | 明确权衡后的选择 | 为了赶deadline跳过设计 |
| 无意债务 | 不了解最佳实践 | 不知SOLID原则而违反 |
| 鲁莽债务 | 知道不对但不管 | 明知该写测试但不写 |
| 谨慎债务 | 知道风险但有意为之 | 原型验证时快速实现 |
| 来源 | 说明 |
|---|
| 时间压力 | 赶进度牺牲质量 |
| 知识不足 | 不了解最佳实践 |
| 需求变更 | 原有设计不再适用 |
| 团队变动 | 人员流动导致知识丢失 |
| 技术演进 | 框架/库版本过时 |
| 缺乏重构 | 从不偿还债务 |
| 方法 | 说明 | 工具 |
|---|
| 静态分析 | 自动检测代码问题 | SonarQube、ESLint |
| 代码审查 | 人工发现设计问题 | PR Review |
| 架构评审 | 评估架构合理性 | ADR |
| 开发者调查 | 团队感知的痛点 | 问卷/访谈 |
| 缺陷分析 | 高频修改的模块 | Git热点分析 |
| 信号 | 含义 |
|---|
| 修改一个功能需改多个文件 | 高耦合 |
| 新人理解代码需要很长时间 | 可读性差 |
| 添加简单功能需要很长时间 | 设计不灵活 |
| 测试困难 | 依赖过多 |
| 频繁出现回归Bug | 缺乏测试覆盖 |
SQALE（Software Quality Assessment based on Lifecycle Expectations）将技术债务量化为修复时间：
TD=∑i=1nRemediationTimei
| 质量特性 | 典型债务 |
|---|
| 可测试性 | 缺少测试、依赖难以Mock |
| 可维护性 | 代码重复、圈复杂度高 |
| 可修改性 | 硬编码、紧耦合 |
| 可靠性 | 未处理异常、资源泄露 |
| 可移植性 | 平台依赖 |
债务比率=开发总投入（时间）技术债务（修复时间）
| 比率 | 等级 | 建议 |
|---|
| <5% | 优秀 | 保持 |
| 5%~10% | 良好 | 定期偿还 |
| 10%~20% | 警告 | 需要专项偿还 |
| >20% | 危险 | 立即行动 |
| 原则 | 说明 |
|---|
| 童子军规则 | 每次修改让代码比之前更好 |
| 渐进式偿还 | 小步持续改进 |
| ROI优先 | 先偿还收益最高的债务 |
| 与功能结合 | 新功能开发时顺便重构 |
| 定期专项 | 每Sprint分配20%时间 |
1. 盘点: 列出所有技术债务项
2. 评估: 每项的影响和修复成本
3. 排序: 按ROI排序
4. 计划: 分配到Sprint Backlog
5. 执行: 按计划偿还
6. 验证: 确认债务已消除
| ID | 描述 | 影响 | 修复成本 | ROI | 优先级 |
|---|
| TD-01 | 订单模块圈复杂度>30 | 高 | 3天 | 高 | P0 |
| TD-02 | 缺少单元测试 | 中 | 5天 | 中 | P1 |
| TD-03 | 日志框架版本过旧 | 低 | 1天 | 中 | P2 |
| 措施 | 说明 |
|---|
| 编码规范 | 统一代码风格和最佳实践 |
| 代码审查 | PR合并前必须审查 |
| 持续集成 | 自动化构建和测试 |
| 静态分析 | 自动检测代码问题 |
| 架构决策记录 | 记录设计决策和权衡 |
| 技术雷达 | 跟踪技术趋势和风险 |
每个Sprint预留固定比例（如20%）的时间用于偿还技术债务：
Sprint容量: 100故事点
├── 新功能: 70故事点
├── Bug修复: 10故事点
└── 技术债务: 20故事点