上周在软件大道负一楼的奶茶店碰着前组的老周，他攥着半杯芋泥啵啵，脸皱得像被甲方改了八版的原型。为啥？他们组刚赶完双11的大促版本，上线之后一周，光给核心下单链路补注释、拆耦合的旧模块，就花了三个研发整周。换谁都得郁闷。
别把技术债全算成研发的“偷懒账”
很多团队一提到技术债，第一反应就是研发当初写代码偷工减料、不做review，才攒下这么多烂摊子。真不是。
就说老周他们组的那堆耦合代码，当初是为了赶618的活动节点，把用户优惠券的校验逻辑直接硬编码到了下单接口里。当时算的明明白白，要是按正常的分层架构设计，光抽离公共校验模块就要多花3天，但是整个活动的开发档期就给了5天，不上的话运营那边的满减活动赶不上预热期，全组的KPI都得受影响。这种债是业务主动权衡之后选的，不是谁懒。
我见过最离谱的团队，把三年前离职员工写的一个没人动过的内部工具脚本，也算进技术债总额。最后扫出来的数大到CTO直接批了两百万的重构预算，结果钱花了一半才发现，那个脚本一年就被调用两次，连测试的必要都没有。
技术债的来源本来就杂。有赶档期主动背的，有版本迭代快漏了的兼容逻辑，还有新人刚上手没来得及打磨的坑。量化的第一步，从来不是上来就扫代码出个总数，而是先给每一笔债标清楚来历——哪些是为了业务发展主动付的“利息”，哪些是没人管攒出来的“糊涂账”。
技术债量化别搞虚的，要算真金白银的成本
现在太多团队做技术债量化，就是拿代码扫描工具跑一遍，出个报告说“当前代码异味3200个，安全漏洞17处”。这种数有屁用。
我之前在河西的一个电商团队待过，他们当初也被这种虚数折腾过。一开始觉得3000多个异味是天大的窟窿，打算全组停掉业务需求花三个月清完，结果拉了个会统计才发现，这里面有2000多个异味是在内部管理后台的代码里，那个后台一年也就运营点进来十几次，根本没人在乎好不好看。
后来他们换了个算法，不算代码的颜值分，只算真金白银的成本。就拿那个硬编码优惠券的接口举例，他们翻了过去半年的迭代记录，发现每次因为优惠券规则调整，要改那三段硬编码，平均要花2个研发天，还要走完提测、回归、上线的全流程，平均每次会触发0.3个小故障，大概影响1%的下单用户，算下来一年因为这几处代码，要烧掉12个研发天，还要承担差不多两万块的故障赔付成本。
真正有用的技术债量化，从来不是算代码的“颜值分”，而是算每一笔债未来会吃掉多少团队的产能、会造成多少可预期的故障损失。
别整那些复杂的金融模型，什么债务利息率、债务现值，普通小团队哪有那个精力算？就拿个共享在线表格，每一笔债记三个数：第一次触发这个问题要花多少时间修，未来平均多久会触发一次，触发一次会造成多少业务影响。算出来的数，比任何专业咨询公司给的报告都靠谱。
偿还计划别喊口号，要嵌进每个迭代的缝隙里
很多团队一想到还债，第一反应就是搞个为期三个月的“重构专项”，全组停掉所有新业务需求，啥功能都不做，专门清旧代码。结果呢？做了两周，老板就坐不住了，问怎么竞争对手都上新功能了我们还在改旧代码，最后专项草草收场，债没还多少，团队士气还掉了一半。
真没必要这么极端。
我之前待的团队，试过把还债的任务嵌进每个迭代的缝隙里。每个迭代固定拿出20%的研发产能，专门用来还排在成本表最前面的那几笔债。比如上次要改优惠券的校验逻辑，本来是个纯业务需求，我们就顺带着把之前硬编码的部分抽到了独立的公共服务里，根本不需要专门抽时间做重构。
最舒服的还债方式，是在每次和业务需求打交道的过程里顺带着把坑填了，而不是专门腾出整块的时间去“还债”。
一开始大家还觉得这是额外负担，跑了三个月才发现，每次提测的bug数量直接降了40%。之前那些经常触发的坑，在顺带着改的时候就填上了，研发不用每次临时救火，反而省了不少时间。到后来发版的时候，大家再也不用提心吊胆盯三个小时的核心链路，发完版直接约着去南湖吃鸭子，谁还会觉得还债是负担啊。
上周碰到老周的时候，我给他出了个主意，让他们先把那三个耦合的下单模块拆出来，每次迭代抽15%的时间慢慢改，别一上来就喊着要全量重构。他听完眼睛亮了，说之前总觉得技术债是个要花大价钱填的无底洞，原来拆成小份，根本没那么吓人。