上周在珠江路的咖啡馆，跟个做电商SaaS的技术负责人唠了俩小时。他刚为大促的线上故障赔了快20万。
排查到最后才发现，两年前赶版本上线时，为了省三天工时砍掉的支付回调异常重试逻辑，现在改个满减规则都要牵一发动全身。之前总觉得技术债是虚头巴脑的行业黑话，直到客诉单堆到客服系统宕机，才反应过来——这玩意儿真的是要掏真金白银还的。
别拿技术债当万能挡箭牌
很多团队一提到代码质量差，张口就甩”技术债”三个字。
真不是。
你刚入职的新人写的逻辑绕得像迷宫的后台接口，那是能力适配问题；产品经理半夜临时改需求，导致前端页面写了八套判断逻辑，那是需求管理的锅；甚至连服务器配置没对齐导致的部署失败，也有人往技术债上靠。
说白了，真正的技术债，是当初为了赶某个明确的时间节点，主动或被动选择了次优方案，后续必须投入额外成本才能补上的窟窿。那些从一开始就没按规范写的代码，顶多算烂账，不配叫技术债。
划清这个边界很重要。不然最后盘点的时候，整个团队把所有写得不顺眼的代码都算成债，列出来几百条，根本不知道从哪下手。
量化不是拍脑袋报工时
说到量化，太多团队的操作就是拉个会，让每个开发对着自己写的老代码估个重构工时，最后加总出来一个吓人的数字，给老板看了就说”你看我们欠了这么多债，得给资源”。
扯不扯？
上次见过个团队，把一个半年前就下线的活动页面，评成了最高优先级的技术债。原因是写那个页面的开发马上要离职，想走之前把代码重构完，好把绩效表填得好看点。这种量化，最后只会变成内部抢资源的游戏，根本解决不了实际问题。
我帮那个珠江路的团队梳理的时候，根本没让大家拍脑袋报工时，而是拆了三个实打实的评估维度：
第一个是故障影响面，比如支付模块的逻辑出问题，是直接卡营收的，权重直接拉满；要是后台某个统计模块的老代码，坏了顶多让运营多花半小时导个表，权重就压到最低。
第二个是修改触发频率，像那个满减规则模块，大促前每个月要改三四次，每次改都要踩老代码的坑，那优先级就比一年动不了一次的老接口高得多。
第三个是隐性维护成本，比如没有注释的老支付逻辑，每次新人接手要花三天才能摸清楚调用链路，这三天的时间成本，全都是之前欠的债。
算下来没花三天时间，之前列的120多条所谓的”技术债”，直接筛掉了80条——要么是根本不算债的烂账，要么是马上要下线的功能，压根不需要额外投入。剩下的40条，按三个维度打分排完序，哪些要先处理，一目了然。
偿还计划别搞成专项重构
很多团队一提到还技术债，第一反应就是要抽一个月时间，关起门来搞专项重构。
别信。
只要业务还在跑，你根本抽不出整块的时间。上次有个团队跟我说，要花三个月重构整个用户中心，结果刚搞了一周，业务那边说要上会员新功能，直接把重构的资源全砍了，最后半拉子工程留着，比之前的老代码还难维护。
那个珠江路的团队现在的做法就很务实：每个迭代固定留20%的容量，专门用来填排好优先级的坑。不是专门抽一周时间把整个支付模块重写，而是每次要改支付相关的新需求时，顺手把相邻的老坑填一点——这次要加新的满减规则，就顺手把之前写死的回调状态码改成枚举；下次要加新的支付渠道，就顺手把之前没做的异常重试逻辑补上。
算下来，他们花了不到两个月的时间，现在改满减规则的耗时，从之前的2人天降到了2小时，上周大促预演的时候，支付模块一次都没崩。
不过话说回来，也不是所有的债都要还。比如那个马上要全量替换的老ERP接口，虽然代码写得烂，但是再过两个月就完全下线了，那就没必要花时间重构，等它自然淘汰就行。
上周那个技术负责人给我发消息，说现在团队排期的时候，再也不会为了”要不要重构”的事儿跟产品吵架了。毕竟债在哪，要花多少成本，还了之后能省多少事儿，都是明明白白的数字。
哦对，他说上次唠完喝的那杯冰美式，比之前花的20万客诉补偿值多了。