技术债这笔账，什么时候还最合适

你是不是遇到过这种情况：一个新功能，以前三天就能上线，现在要两周；改一个小 bug，会引出三个新的；团队里没人敢动某块代码，因为"不知道会牵连什么"。

这就是技术债。它不像设备折旧那样写在财务报表上，但它在真实地消耗你的时间和金钱。

技术债是怎么欠下的

技术债不是一天欠下的，通常是这几种情况的叠加：

赶工期留下的后遗症。半年前为了赶一个展会，有个模块写得比较粗糙，当时想"以后再优化"。结果展会过了，功能还在跑，但那块代码成了禁区——谁碰谁出问题。

业务变了，代码没跟上。三年前设计的系统，当时一天一百单够用了。现在一天一千单，某些环节开始卡顿，但整个结构是按当年的假设搭的，动一处就要动全局。

人走了，知识也走了。老员工离职时交接了一份文档，但真正关键的逻辑只在某些人的脑子里。新人接手后不敢改，只能在外面加一层又一层，系统变得越来越复杂。

技术过时了，但还能跑。用的框架已经停止维护，社区找不到人问问题，招人也招不到愿意维护老技术的。但系统稳定，没人敢提"升级"。

技术债的成本怎么算

技术债不是免费的。它在三个地方吃你的利润：

开发速度变慢。同一个功能，别人家的团队一周上线，你要三周。这意味着你错过市场窗口，或者同样的研发投入产出更少。

故障成本增加。系统越复杂，出问题的概率越高。一次线上故障，排查要半天，修复要一天，期间业务停摆、客户投诉、团队加班——这些成本加起来远超当初省下的那几天开发时间。

人才流失。优秀的工程师不愿意维护烂代码。他们觉得在这里学不到东西，没有成就感，于是离开。留下来的人要么习惯了凑合，要么能力不足以重构。

算一笔账：如果一个模块每次改都要多花三天，一年改二十次，就是六十天。一个高级工程师的日薪加社保大约一千五，六十天就是九万。这还只是直接成本，没算错过机会的损失。

什么时候该还技术债

不是所有技术债都要立刻还。有些债可以扛着，有些必须马上处理。判断标准是：

这块代码还会继续改吗？ 如果一个模块已经稳定，半年都不需要动一次，那它即使写得不好，也不会持续产生成本。可以暂时不管。

它是不是挡住了新功能？ 如果每次做新需求都要绕开某个模块，或者在它上面打补丁，那它已经在拖慢你的业务了。

团队是不是开始怕它？ 如果没人敢碰某块代码，或者每次改它都要全员加班盯着，那它已经成了心理负担，会影响团队士气。

招人的时候是不是成了障碍？ 如果面试的人看到代码质量后不愿意来，或者新人入职后要三个月才能上手，那技术债已经在影响你的组织能力。

满足任何一条，就该考虑还债了。

还债的三种姿势

还技术债不是"停下来重构半年"。有三种更灵活的方式：

童子军规则——每次改这个模块，顺手清理一点。不专门立项，但每次需求涉及到它，就花半天把相关的代码整理一下。半年下来，核心模块就干净了。

隔离法——把烂代码包起来，不让它污染新代码。新功能的逻辑写在新的模块里，只通过一个清晰的接口和老代码打交道。这样新代码保持干净，老代码的影响范围被限制住。

专项重构——如果某个模块已经严重拖慢开发速度，那就专门排一个迭代，用两到三周集中处理。前提是你能算清楚这笔账：重构花三周，但之后每个需求省一周，十个需求后就回本了。

怎么防止继续欠债

还债是一方面，更重要的是防止新债。三件事可以做：

代码评审不是走形式。每次合并代码，至少要有一个人看过。不是为了挑刺，而是为了确保逻辑清晰、没有明显的坑。

技术债要看得见。维护一份清单，记录哪些地方是凑合的、哪些地方以后要改。每个季度看一次，决定哪些该处理了。

给重构留时间。每个迭代留出 20% 的时间做清理，不要全部排满需求。这 20% 是在保护你未来的开发速度。

读完能做什么决定

• 技术债在三个地方吃利润：开发速度、故障成本、人才流失
• 满足"还会继续改""挡住新功能""团队怕它""影响招人"任何一条，就该还债了
• 还债有三种姿势：童子军规则、隔离法、专项重构，不必停下来半年
• 防止新债靠三件事：代码评审、债务清单、每个迭代留 20% 时间重构