技术债务 = 为了短期利益而做的次优技术决策

类比金融债务：
- 借债（技术债务）可以获得短期利益（快速交付）
- 但需要支付利息（维护成本增加）
- 需要偿还（重构、重写）

技术债务 vs Bug：
- Bug：代码没有按预期工作
- 技术债务：代码能工作，但难以维护/扩展

按产生原因分类：

1. 故意债务（Deliberate）
   - 明知故犯，为了赶工期
   - "我们知道这不好，但先这样吧"
   - 需要追踪和计划偿还

2. 无意债务（Inadvertent）
   - 不知道更好的做法
   - "我们现在才知道应该这样做"
   - 需要培训和知识共享

按偿还难度分类：

1. 轻量债务
   - 命名不好、缺少注释
   - 容易发现和修复

2. 中等债务
   - 重复代码、过长方法
   - 需要重构

3. 重度债务
   - 架构问题、技术栈过时
   - 需要大规模重写

Google 的技术债务管理：

1. 代码注释标记
   // TODO(bugId): 描述
   // FIXME: 描述
   // HACK: 描述

2. Bug 追踪系统
   - 创建技术债务 Bug
   - 标记优先级和影响
   - 纳入迭代计划

3. 技术债务看板
   - 可视化所有债务
   - 追踪偿还进度
   - 按影响排序

4. 定期审查
   - 每个迭代审查债务
   - 分配偿还时间
   - 追踪趋势

偿还策略：

1. 童子军规则
   - "让营地比你来时更干净"
   - 每次修改代码时顺手改善

2. 专项偿还
   - 分配专门的迭代偿还债务
   - 通常 20% 的时间用于技术改进

3. 绞杀者模式
   - 逐步替换旧代码
   - 新功能用新代码实现

4. 预防债务
   - 代码审查关注债务
   - 自动化检测债务
   - 建立编码标准

平衡新功能 vs 债务偿还：
- Google 建议 20% 时间用于技术改进
- 太少：债务积累，系统腐化
- 太多：新功能交付慢

技术债务清单：

| ID | 描述 | 类型 | 影响 | 优先级 | 状态 |
|----|------|------|------|--------|------|
| TD-001 | OrderService 过长（2000行） | 中等 | 高 | P1 | 计划中 |
| TD-002 | 缺少集成测试 | 中等 | 高 | P1 | 进行中 |
| TD-003 | 硬编码的配置值 | 轻量 | 中 | P2 | 待处理 |
| TD-004 | 使用已废弃的库 | 重度 | 高 | P1 | 计划中 |
| TD-005 | 重复的用户验证逻辑 | 中等 | 中 | P2 | 待处理 |

偿还计划：
- Sprint 1: 修复 TD-002（集成测试）
- Sprint 2: 开始 TD-001（拆分 OrderService）
- Sprint 3: 完成 TD-001，开始 TD-004