工程债的利息计算器：小团队如何在「修」与「扛」之间做选择

一个让所有开发者沉默的问题

“这段代码太烂了，必须重构。”

这句话我听过几十次，也说过几十次。但真正让我开始警惕的，是后来每次重构完，并没有出现预期中的效率飞跃——而是新的 bug、新的兼容问题和一封“改完这个之后原来能跑的功能坏了”的投诉邮件。

问题是：我们到底该怎么判断，眼前这坨代码到底是该咬牙修掉，还是继续忍下去？

在小团队，你没有大厂的资本去“先还债再开发”，也没有那种“每个 Sprint 固定 20% 时间修 bug”的奢侈。你必须把每一小时人工当成现金来花。

所以我慢慢摸索出了一个很朴素的判断方法——我管它叫“工程债利息计算器”。

利息计算器的三个核心指标

先明确我的前提：技术债务不是绝对不能欠。很多系统初期就是靠“先跑通”活下来的。欠债不可怕，可怕的是你不知道这笔债的利息有多高，以及什么时候会爆。

我只看三件事：

1. 变更代价函数：每次改这个模块，平均额外花多少冤枉时间

简单做法：连续跟踪 5 次对该模块的修改（修复 bug、加功能、改配置都算）。记录“理想时间”和“实际时间”——理想时间是指如果代码干净、文档清晰的情况下预估需要的时间。

假设某模块每次改动的实际耗时是理想时间的 3 倍以上，那这笔债已经高到值得警醒了。

示例：我们之前做的一个 AI 写作工具的提示词解析模块，因为历史原因里面嵌了三个不同版本的格式校验逻辑，每次加新 prompt 模板都要花半天来调试解析异常。成本是理想值的 4.2 倍。后来花 1.5 天统一成一套校验后，后续 10 次改动累计节省超过 6 天。

2. 故障风险敞口：不改的话，未来三个月可能因此出几次线上事故

这个很难精确预测，但可以用一个简单估算：过去三个月因为这个代码问题出了几次故障？每次故障的恢复时间？影响了多少用户？

把这三个数字乘起来，得到一个“风险积分”。然后问自己：如果现在花 X 小时去重构，能把未来三个月的风险积分降低多少？

假设重构后风险积分从 150 降到 15，而重构耗时为 25 小时，每降低 1 分风险需要约 0.18 小时——这个效率很高的，值得做。反之如果重构耗时 80 小时，每降低 1 分需要 0.59 小时，那可能优先做其他高回报的事情。

3. 团队认知损耗：新人上手该模块需要额外学多少“潜规则”

这是最难量化但最伤团队的。如果每次新成员（或者隔了一个月没碰的你自己）看代码都要花多半天来理解那些“为什么这里要加这个 flag”“为什么这个函数有副作用但没注释”，则说明认知债务很高。

我会记一笔：每次有人问“这里为什么要这么写”——记录次数。超过 3 次且没有合理文档支撑，就说明这笔债需要还。

决策四象限

把上面三个指标简化为两个维度：修改频率（高/低）和影响严重度（高/低）。

• 高频率 + 高严重影响：必须尽快重构，这是毒瘤。
• 高频率 + 低严重影响：考虑局部优化，不要大改。比如只改最常走的那条路径，其余保持不动。
• 低频率 + 高严重影响：低频率但一旦出事就完蛋，加防御性代码（比如断言、日志、熔断）比深度重构更划算。
• 低频率 + 低严重影响：放着别动，等下一次修改时顺带清理，不要专门立项。

一个真实（假设）的案例

假设你维护一个语言学习 App 的生词本同步模块。代码是一年前匆忙写的，没有单元测试，数据库迁移脚本靠手动执行。最近三个月改了 6 次，每次都需要反复测试同步逻辑，平均额外浪费 2 小时。出过两次数据不一致的事故（用户生词丢失，虽然恢复但收到投诉）。新人入职后花了两天才敢动这个模块。

按我的计算器：变更代价 > 3 倍，风险积分 = 2 次事故 × 3 小时恢复 × 50 受影响用户 = 300 分，认知损耗记录有 4 次疑问。

这个是典型的高频率 + 高严重影响。我会建议花 3～5 天时间彻底重写同步模块，加上自动化测试和迁移脚本。预期收益：后续每次修改节省 2 小时，未来三个月减少 2 次事故风险，认知成本基本消除。

什么时候不该还债

也得说说反例。

有时候一个模块改动频率极低（一年动一次），尽管代码写得像屎，但每次改动时即便多花两小时，一年就两小时。为了这两小时去花两天重构，不值得。

更要命的是，重构本身会引入新风险。如果这个模块是边缘业务，重构后的长期收益根本覆盖不了短期的机会成本。我见过小团队把整个后台管理系统重写，用了两个月——那两个月里销售和市场找不到人改 CRM 规则，损失了几单，后来算账发现不重构的话，那些单子的利润足够雇一个人专门维护老代码。

所以我的立场很明确：不要为了“代码干净”去还债，要为了“业务痛”去还债。 这和之前写过的《重构的时机不是代码乱，而是业务痛》一脉相承，但当时讲的是 App 架构演进的决策，今天更聚焦在单模块的应急判断。

实际操作清单

如果你是小团队的 tech lead，想开始量化技术债务，我建议你按这个清单来：

1. 选出一个你最头疼的模块。
2. 收集过去三个月对该模块的修改次数和每次额外时间（问 Git log 和你的工时记录）。
3. 统计过去三个月因该模块导致的线上故障次数、影响范围和修复耗时。
4. 最近一个月内，团队成员对这个模块有过几次疑问（可以简单在群里记录）。
5. 评估重构预计耗时（不要过分乐观，通常要再乘以 1.5）。
6. 利用前文的“风险积分”和“变更代价”粗略判断。
7. 做决定：还债、局部优化、加防护、或标记为“下次动的时候顺带修”。
8. 如果决定还债，排进迭代时务必给出明确的结束标准：“重构后，对于同样的需求变更，耗时降低到多少以下；故障率降低到多少以下。”

最后一句

技术债务从来不是道德问题，而是经济决策。不欠债的不会死，欠了债不会算账的才会。

PaxLee