Tech Debt

解决什么问题：让"今天偷的懒"不变成"明天的灾难"—— 不承认技术债 = 拖到系统无法维护； 主动管理技术债 = 债在可控范围内，利息可承受。

它是什么

技术债（Tech Debt） 是为了短期速度而做的长期妥协—— 快速但不完美的代码、架构、设计决策，未来需要还债（重构）。

技术债的类型：
  ┌──────────────────────────────────────────────────┐
  │  代码债    - 代码可读性差、重复、难维护            │
  │  架构债    - 单体硬撑、微服务混乱、边界模糊        │
  │  测试债    - 覆盖率低、关键路径无测                │
  │  文档债    - 文档缺失、过时、误导                  │
  │  依赖债    - 老旧依赖、安全漏洞、版本不统一        │
  │  性能债    - 不重构不优化，靠堆机器硬撑            │
  └──────────────────────────────────────────────────┘

SE@G Ch 15（"Deprecation"）： "Code is a liability. Every line of code you write is a future maintenance burden. The question is not 'should we have any code?' but 'which code is worth keeping, and which is debt?"

V2 视角（V2 B6 + B7）：技术债是权衡的具象化—— V2 B6 说"没有完美解"——技术债就是那些"为了快而牺牲的维度"。 关键不是"消灭技术债"（不可能），是让债在可控范围。

关键属性

属性	值/含义
不可避免	任何真实工程都有技术债
有利息	不还债 = 改新功能越来越慢
有本金	还债需要投入（人力 / 时间 / 风险）
可识别	必须能列出（不是"我感觉有债"）
可量化	影响范围、修复成本、改动风险
可排期	像新功能一样排进迭代
有负责人	谁负责还 / 谁负责付利息
可沟通	非技术人员也要懂（特别是债务带来的风险）

怎么用

场景 1：技术债的可视化

方法 1：技术债清单（公开可见）
  - ID
  - 描述（什么问题）
  - 类型（代码 / 架构 / 测试 / 文档）
  - 影响（哪些功能 / 哪些用户）
  - 修复成本（人天）
  - 紧迫度（高 / 中 / 低）
  - 负责人
  - 计划还债日期

方法 2：技术债仪表盘
  ┌────────────────────────┬───────────┐
  │ 模块 A                  │ 债密度 15 │  ← LOC / 维护人
  │ 模块 B                  │ 债密度 30 │  ← 红色预警
  │ 模块 C                  │ 债密度 8  │
  └────────────────────────┴───────────┘

方法 3：SLO 视角
  "这个服务因为老代码，每次改要 3 天"
  "上线故障率从 1% 升到 5% 是因为技术债"
  → 把技术债的影响量化到 SLO 层面

场景 2：技术债的还债策略

策略 1：还利息（短期）
  - 改一处代码同时清理周围的小债
  - 不主动大重构，但顺手小修

策略 2：付本金（中期）
  - 专门排迭代做技术债
  - 通常一个迭代 10-20% 时间用于还债

策略 3：重组（长期）
  - 整个模块重写（很少用，风险大）
  - 通常只在系统濒临崩溃时用

EDM Ch 17：技术债和金融债一样，
关键不是"不欠债"，是"债/资产比"在合理区间。

场景 3：何时该还债 vs 何时该扛着

该还债的信号：
  ✗ 改一个功能从 1 天变成 3 天
  ✗ 故障率因为代码质量上升
  ✗ 关键人员离职后无法维护
  ✗ 招聘新人看不懂代码
  ✗ 安全漏洞因依赖债

可以扛着的信号：
  ✓ 模块稳定 / 不再改动
  ✓ 业务可能下线 / 替换
  ✓ 还债风险大于收益
  ✓ 影响范围小 / 边界清晰
  ✓ 收益 < 投入

决策框架：
  1. 列出来：所有已知的技术债
  2. 评估：影响 / 修复成本 / 风险
  3. 排序：先还"高影响、低成本"的债
  4. 排期：像新功能一样排进迭代

场景 4：技术债与新功能的平衡

常见错误 1：只做新功能，永不还债
  → 债越滚越大，最后崩盘

常见错误 2：停止新功能，全力还债
  → 业务无法发展，团队被裁

正确做法：
  - 每个迭代预留 10-20% 时间给还债
  - 用数据决定还什么债（影响最大优先）
  - 借机还债（改相关代码时一并清理）

SE@G Ch 15："Deprecation is not optional"——
不是"要不要消灭技术债"，是"按什么节奏消灭"。

常见误区

1. "技术债 = 烂代码"——错。技术债是有意识权衡——烂代码是债，但债不等于烂代码
2. "消灭技术债"——错。消灭不了——任何工程都有债
3. "技术债 = 工程师的错"——错。技术债是商业决策—— "快速上线拿融资" = 业务主动选择欠债
4. "技术债不上线 / 不重要"——错。技术债直接影响业务——慢改 = 错过市场窗口
5. "靠新人解决技术债"——错。新人看不懂 = 债变本 + 利息——必须主动还而非被动拖

关键洞察

技术债 = 工程界的"金融债"——关键不是"不欠债"，是"债在可控范围"。

不承认债的团队最后崩盘； 只还债不做事的团队最后饿死； 承认债、量化债、节奏化还债的团队才是健康的。

相关链接

• 发布——还债的载体
• 数据驱动——用数据决定还什么债
• SLO——技术债影响 SLO 时必须还
• Postmortem——技术债导致的事故
• [V3 涌现作为] · 权衡——技术债是权衡的产物
• [V3 涌现之时] · 演化——技术债管理 = 持续演化