技术债量化与偿还计划落地手记

上周三在软件大道路边的便利店买冰美式，撞见之前带的小弟，抱着电脑蹲在路牙子上挠头。

问咋了？

说老板要他们这周把技术债的账算清楚，还要出个偿还方案，不然下季度的新功能排期不给批。

他攒了三页纸的清单，从前端的样式混乱到数据库的索引缺失，列了37项，自己看着都头大，不知道从哪下手。

别拿“感觉有债”当量化标准

很多团队聊技术债，全靠拍脑袋。

“这个模块代码写得太烂，要重构，大概20人天。”

“上次赶需求留的临时逻辑，现在跑着也没啥问题，先不管。”

这哪是量化，是玄学。

我见过最落地的量化方式，根本不需要什么复杂的工具，就抓两个核心数：

最近3个迭代的额外修复工时占比。

啥意思？就是每次迭代排了100人天的开发量，最后实际花了多少时间在给老代码擦屁股？比如那个小弟的团队，之前赶618活动的时候，把支付回调的逻辑硬塞到了用户表的更新接口里，省了三天开发量，现在每次改用户相关的功能，都要怕碰坏支付逻辑。上个月改个用户昵称的字段，不小心把回调的重试次数改了，导致1200多笔订单的支付状态没同步，赔了快两万的优惠券。算下来，最近三个迭代，他们有42%的工时，全在给当时的临时方案擦屁股。

第二个数是线上故障的关联占比。

拉一下最近半年的故障记录，有多少是因为当时赶需求写的临时逻辑没做异常兜底、没补测试用例导致的？这个数一摆，老板立刻就能明白，技术债不是开发嫌代码不好看，是真的在花钱。

很多团队量化的时候，为了显得账做得细，把所有能想到的小问题全列进去，比如变量名写得太短、代码注释不够，这些全算成债，最后清单长的没人愿意看。

纯没用。

偿还计划不是排期表，是动态的优先级排序

那个小弟一开始的计划，是把37项债按出现时间排序，从最早的开始还。

这就是典型的学生思维。

你想啊，三年前写的一个老后台的导出功能，现在只有行政的同事每个月用一次，就算有bug，大不了手动导，你花两周时间去重构它，有啥意义？

真正的偿还计划，根本不是排期表，是动态的优先级排序。

直接影响收入的债，优先级最高。

比如刚才说的支付回调和用户逻辑混在一起的问题，每次出故障都要赔钱，那肯定优先还。不用一下子全拆完，每次迭代拿15%的工时，先把支付逻辑抽成独立的方法，补全测试用例，再慢慢迁成独立的服务，两三个迭代就能搞定。

那种不影响线上运行，只是开发写着别扭的债，比如变量名写的a、b、c，完全可以等下次改这个模块的时候顺手改了，不用专门排期。我之前见过有团队为了还“代码注释率不够”的债，专门花一周时间给老代码补注释，补的全是“这个方法是处理用户的”这种废话，纯浪费时间。

给业务方讲偿还计划的时候，别讲“我们要优化代码质量”，要算实实在在的账。比如拆完支付逻辑之后，以后改用户相关的功能，每次能省至少2天的测试时间，不会再出现支付状态不同步的问题，下季度上那个大客户的定制需求，能快一周上线。业务方算得明白这个账，才会给你留工时，不然永远觉得你是在摸鱼。

还有，计划要留缓冲。别把每个迭代拿出来的15%的工时全排满，要留三分之一的弹性，万一突然出个小的线上故障，或者业务那边有个紧急的小需求，不能说因为要还技术债，就把线上问题压下去，那反而会滚出更大的坏账。

别等债滚成坏账了再想着处理

很多团队的技术债，都是这么滚出来的。

每次赶需求的时候，大家都觉得“就这一次，下次再改”。结果下次的需求比这次还急，永远没有下次。

我之前在南京待的那个老项目，当时赶上线，直接跳过了数据库分库分表的步骤，所有数据全存在一个库里。现在单表已经到了1200万行，每次查询都要扫200万行数据，慢得要死。现在要重构的话，至少要3个月的开发量，还要停服两次，这就是坏账了。当初要是每次迭代拿10%的工时，慢慢把历史数据迁出去，根本不用现在这么麻烦。

现在那个项目组的做法很简单，每个迭代开需求评审会的时候，多问一句：这次的临时方案，要记到技术债台账里不？

别等过了半年，大家都忘了当时写的临时逻辑是干啥的，出了问题再翻代码，那成本就高了。

哦对，本来开发这行，就没有零负债的完美系统。

你要是一点债都不留，所有代码都按最规范的写，那大概率你上功能的速度比竞争对手慢一半，早就被市场干没了。

上周和那个小弟分开的时候，他已经把之前列的37项技术债砍到了7项。剩下的那些没用的，直接标成了“可接受的负债”，比如变量名不规范的，就说以后改的时候顺手弄，不用专门管。

他说这次给老板汇报的时候，直接把之前每次迭代擦屁股的工时占比，还有故障的损失金额列出来，老板当场就批了每个迭代拿15%的工时出来还优先级最高的那几个债。