技术债治理实战

适用：业务压力大、历史代码多、重构诉求强的研发团队

一、什么是「真技术债」？

类型	示例	利息（持续成本）
架构债	单体无法水平扩展	每次大促扩容困难
代码债	无测试的核心模块	改一行崩三处
测试债	E2E 覆盖 < 10%	发布信心低
基础设施债	JDK 8、EOL 中间件	安全漏洞
文档债	onboarding 靠 oral	新人 3 月上手

不是技术债：产品需求变更、合理的技术探索失败。

---

二、债务登记制度

每个 Sprint 允许创建 Debt Ticket，必填：

## 债务描述
## 产生原因（何时、为何欠下）
## 影响范围（模块、团队）
## 利息估算（每 Sprint 浪费人天）
## 还债方案（≤ 3 天可完成切片）
## 验收标准

统一标签：tech-debt，Product Owner 可见不可删。

---

三、优先级矩阵

        高影响
          │
   Q2 规划 │ Q1 立即
   ────────┼────────
   Q4 忽略 │ Q3 顺手
          │
        低影响 ←── 低成本 ──→ 高成本

• Q1：高影响低成本，下 Sprint 必做（如升级有 CVE 的依赖）
• Q2：高影响高成本，拆 Epic 分季度（如模块拆分）
• Q3：Boy Scout——改文件时顺手修
• Q4：归档，不主动做

---

四、20% 容量规则

每个 Sprint 预留 15–20% 容量 给技术债，PO 与 Tech Lead 共同排期。

Sprint 容量 100 点 = 80 业务 + 20 还债

不可协商：安全 CVE、合规、生产 P0 根因修复。

---

五、Boy Scout 原则

「离开营地比来时更干净」：

• 改 OrderService 时，补一个缺失的单测
• 发现魔法数，提取常量（不扩大 scope）
• 过时注释删掉

MR 模板增加：本 PR 顺带修复的债务（如有）。

---

六、Architecture Review

每季度 半天 Archery：

1. 各团队报 Top 3 债务
2. 架构师评估系统性风险
3. 输出 季度还债 Roadmap（3–5 项）

与业务 Roadmap 并列展示，争取管理层支持。

---

七、可量化 KPI

指标	方向
Sonar 技术债比率	↓
核心模块单测覆盖率	↑
平均 PR 规模	↓（小步合并）
生产 incident 中「债务相关」占比	↓
新人 onboarding 天数	↓

---

八、还债策略示例

8.1 绞杀者模式（Strangler）

老单体旁路新建 order-service，流量逐步迁移，非 Big Bang 重写。

8.2 分支 by Abstraction

interface PaymentGateway { ... }
class LegacyPayment implements PaymentGateway { ... }
class NewPayment implements PaymentGateway { ... }
// Feature Flag 切换

---

九、与 PO 的沟通话术

❌ 「代码太烂必须重构两个月」
✅ 「订单模块每 Sprint 多耗 3 人天修 Bug，用 2 个 Sprint 投资可永久省 30% 维护成本」

用业务语言讲利息。

---

十、Checklist

• [ ] 债务 Ticket 模板上线
• [ ] Sprint 20% 容量写入团队公约
• [ ] 季度 Archery 日历 invite
• [ ] KPI Dashboard 可见
• [ ] CVE 24h 评估 SLA

---

十一、案例：订单模块还债两周记

某电商团队订单服务 单测覆盖率 12%，每次改促销规则回归 2 天。

Week 1：

• 登记债务 Ticket，利息估算每 Sprint 3 人天
• 为 PriceCalculator 补 15 个单测（纯函数优先）
• 提取 PromotionEngine 接口，Legacy 实现包一层

Week 2：

• Feature Flag 切换 10% 流量到新引擎
• 监控错误率无异常后全量
• 覆盖率升至 58%，后续需求交付提速约 30%

关键：未停业务开发，20% 容量 + Boy Scout 叠加完成。

---

小结

技术债治理不是「停下来大扫除」，而是 持续小额投资 + 优先级透明 + 度量验证。国内高效团队把还债纳入 Sprint 常例，而非等项目「黄了才重构」。