上周跟南京软件大道出来的老周喝冰啤。
他刚为一个三年前写的破接口赔了笑脸。
618大促的尾端，支付回调超时，系统自动给用户发了五次优惠券。算下来亏了小二十万。
他灌了一口酒，说当初赶上线的时候，哪有时间做幂等，能跑就不错了。
这就是最典型的技术债——赶工的时候省的那点时间，最后连本带利要还十倍。
先算清楚你到底欠了多少债
我见过太多团队谈技术债，上来就整一套代码扫描工具，把所有坏味道列出来，算个综合得分，比如代码健康度82分。
有个屁用。
不要拿抽象的代码评分当技术债的量化标准，老板看不懂，开发也不关心。真正有用的量化，是把每一笔债都换算成具体的、可衡量的成本。
比如老周他们那个没做幂等的支付接口，当初赶上线省了2天的开发时间，现在呢？每次大促要安排3个开发、2个运营人工核对异常订单，每次大促要花掉差不多1.2万的人力成本，还附带万分之三的资损概率。那这个债的量化值就很明确：每季度固定损耗2.4万人力成本+每年平均6000元的潜在资损。
不要搞虚的加权打分。你就列个表，每一笔债对应三个数据：当前每季度的运维/修复成本、可能带来的业务风险金额、修复需要的人力时间。哪怕你只有十笔债，也比搞个上百条的扫描报告有用。
别上来就说要重构
我见过太多团队一提到还技术债，第一反应就是“我们要花三个月把老系统全部重构”。
然后老板问一句：重构期间的业务迭代怎么办？
当场哑火。
技术债的偿还必须嵌入正常的业务迭代流程，不能搞独立的重构项目。你想啊，业务部门每个季度的KPI都压得死紧，你单独拿三个月出来重构，谁给业务做新功能？最后重构项目肯定砍。
正确的做法是，每个迭代固定留20%的开发容量，专门用来还优先级最高的债。比如这个迭代本来要做三个新功能，就挤掉0.6个功能的资源，先把那个支付接口的幂等补上，把那个响应超时的老查询接口拆了。
重点是，你跟老板汇报的时候，别扯“我们要提升代码质量”，你要说“这次把支付接口优化完，以后每次大促能省1.2万的人工核对成本，订单异常率能从千分之五降到万分之二”。
老板听得懂数字，听不懂情怀。
那些没人说的隐性成本
很多人算技术债的时候，只算看得见的运维成本，漏掉了最疼的隐性损耗。
比如老周他们团队，现在新来的开发，要花整整两周才能搞懂整个下单链路的逻辑——因为当年赶上线的时候，没人写注释，所有的逻辑都散在三个不同的服务里。比正常团队的新人上手时间多了10天。按一个中级开发日薪800算，每招一个新人，就要多花8000的培养成本，一年招5个，就是4万的隐性损耗。
还有更隐形的：老团队的开发每次改核心代码都提心吊胆，怕碰坏哪里，天天吐槽破代码没人敢动，待个一两年就离职。核心开发离职的招聘成本，少说也得大几万。
所有的债项都要换算成老板能看懂的成本或收益，你别跟老板说“新人上手慢影响士气”，你要说“把核心链路的文档补全、逻辑理清楚，新人上手时间能缩短60%，每年能省4万的培养成本”。
说实话，技术债从来不是什么洪水猛兽。
没有哪个团队能写出零债的代码，赶业务的时候偷的懒，本来就是要还的。
别等债滚到系统跑不动了、要赔大钱了才想起处理。
你现在写的每一行赶工的代码，最后都会变成你要付的利息。