技术债务治理

技术债是被滥用最多的概念之一。任何看着不顺眼的旧代码都被叫做"技术债"，于是"还债"变成了"我想重写"的借口，重写完发现新代码也很快变成下一轮债。治理技术债的前提，是先想清楚什么是债、什么不是，哪些债值得还、哪些债该让它继续存在。把这件事想明白，才不会陷入"无止境重构却没产出业务价值"的循环。

什么是技术债，什么不是

技术债是为了短期收益而有意做出的、会在未来产生额外成本的工程取舍。关键词是"取舍"——它有当时的理由，也有未来的代价。

text

不是技术债：
  - 只是代码写得丑，但没有影响任何东西
  - 旧技术栈但运行稳定、没人改
  - 你不喜欢但工作正常的实现

是技术债：
  - 为了赶上线跳过了抽象，现在每加个功能都要改十处
  - 没有测试，每次改动都提心吊胆
  - 共享数据库直连，导致无法独立部署

不是所有旧代码都是债。一个运行良好、没人需要改的老模块，哪怕风格过时，也不是债——它是已经还清的旧账。别为了"看着不顺眼"就去动它。

债不是铁板一块，类型不同，处理方式完全不同：

有意债要保留当时的记录（"为什么这么做"），未来还债时不会误判。无意债最危险——团队不知道它的存在，每次踩坑都像第一次发现。

治理的第一步是让债被看见。隐性债是最有害的，它存在于某个老员工的脑子里，人一走就失传。

text

做法：
  - 遇到坑时，立刻在代码里留 TODO / 注释，说明问题和影响
  - 用 issue 跟踪，打上 tech-debt 标签
  - 标注"影响什么"（每次改动多花 X 小时 / 偶发故障 / 阻碍某个功能）

记录的重点不是"这里很烂"，而是"它造成了什么具体成本"。没有具体成本的"烂代码"不构成债，不值得投入。

这是治理中最关键的判断。债像金融债务一样，有的该尽快还，有的可以一直背着：

两种主流偿还节奏：

重写整个系统几乎从来不是好策略。重写的成本和风险巨大，而且重写过程中老系统还在出业务价值，团队往往陷入"新老并行、两头都维护不动"的泥潭。绝大多数债，应当通过渐进式重构逐步偿还。

只还旧债不防新债，等于一边倒水一边漏水。防止新增比偿还更重要：

text

机制：
  - Code Review 时识别新增的债，要求留 TODO 和 issue
  - 有意债要记录"为什么、什么时候还"
  - 关键模块加架构约束（依赖方向、分层规则），CI 校验
  - 给新人讲清楚架构约定，避免无意债

有意债不是问题，没有记录的有意债才是问题。今天的取舍，要写得让三个月后的自己看得懂。

技术债治理最大的障碍，是业务方听不懂"我们要花两个月还技术债"。换个说法：

text

错误沟通：
  "我们要停下来重构，还技术债"
  → 业务：然后呢？不交付功能了？

正确沟通：
  "现在每次加功能都要多花 3 天绕过这段代码，
   重构后能降到半天。两个月内省回来的工时，
   够我们多交付 X 个功能。"

把债翻译成业务能理解的语言：速度、稳定性、风险。还债的正当性来自它对未来交付速度的提升，而不是"代码该干净"这种审美诉求。