技术债量化与偿还计划一线实操笔记
上周去南京河西见老周。他是那家做零售SaaS公司的研发总监，刚在季度排期会上跟老板拍了桌子。
全部门的季度迭代额度被新需求占得满满当当，之前攒了大半年的烂代码，没人愿意碰。线上一周崩三次，运维的同学都快提桶跑路了。
别拿“以后重构”当挡箭牌 先把债算明白
很多团队一提技术债，全是感性判断——这块代码写得烂，那个模块耦合度高，估个重构时间就算完事。真上手做了才发现，当初拍脑袋估的10人天，实际30人天都打不住。
老周他们之前就是这德行。直到去年算过一次细账，才发现之前所谓的“量化”全是自欺欺人。
真正的技术债量化，根本不是算重构要花多少时间，是要算清楚三个实打实的成本：每次因为这段代码出bug的修复时间，每次加新需求因为耦合度高多耗的额外开发时长，还有线上故障直接带来的业务损失。
就拿他们那个支付回调模块来说，当初为了赶618的上线节点，硬塞了三个第三方支付渠道的适配逻辑，没抽公共层。这半年来，每次加新渠道，开发要比正常流程多花2.5天；上个月还因为渠道逻辑冲突，导致支付回调延迟2小时，直接少了12万的成交流水。
哦对，还有个最容易漏算的隐性成本：新人上手时间。那个写得满是“临时改的别问”注释的用户中心模块，新来的后端同事光摸清楚逻辑就花了两周，这部分时间，全是技术债产生的额外消耗。
说个好笑的事。之前有个刚跳槽过来的年轻架构师，上来就拍胸脯说所有不符合最新设计规范的代码都是技术债，要全量重构。把跟了公司五年的老产品经理气得直拍桌子——那个要被重构的老订单模块，每个月给公司贡献几百万的营收，重构搞坏了，他架构师能赔吗？
真的，不是所有旧代码都是技术债。那些稳定跑了好几年、半年没改过、也从来没出过故障的模块，根本不是债，是沉淀的业务资产。别拿着最新的设计规范当标尺，把所有老代码都一竿子打死。
偿还计划不是把重构塞进迭代就完事
很多团队的技术债偿还计划，看起来特别合理：每个迭代挤10%的时间给重构。
实际执行呢？只要新需求排期一紧，这10%的时间第一个被砍。砍个三四次，大家都觉得这事根本不重要，索性全忘了。老周他们之前就这么干，连续三个季度的技术债偿还预算全被新需求吃干净，本来100人天能搞定的事，利滚利到最后要花300人天。
正确的偿还逻辑，根本不是按代码新旧排优先级，是按“当前产生的损失大小”排。已经在持续引发故障、影响核心业务流程的债，优先级最高。
这类债根本不能跟新需求混在同一个迭代里凑排期，要单独列出来，跟老板算明白账：你要是不还，下个月大促的时候可能直接把支付链路搞崩，损失多少流水，影响多少客户留存。账算清楚了，老板自然不会随便砍你的排期。
那些虽然代码写得乱，但半年都没出过问题，也不拖新需求开发速度的债，就往后排，甚至可以不还。省下来的时间去做新功能给公司赚更多钱，这不比闷头搞重构香？
老周他们去年处理那个支付回调的债，根本没花整周的时间搞大重构。就是每次迭代的时候，只要动到这个模块的相关逻辑，就顺手把耦合的部分拆一点——这次加微信渠道适配，就把公共的回调校验逻辑抽出来；下次改支付宝的超时逻辑，就把异常重试的部分单独拎出来。前后花了八周，总共投入12人天，就把攒了一年的债还完了。比当初估的30人天少了快三分之二，全程没耽误新需求上线。
说真的，这种“随用随还”的方式，比专门挤时间搞大重构靠谱太多。大重构搞不好还要引入新的bug，折腾半个月，功能跟之前一模一样，谁看了都觉得是在浪费时间。
最容易踩的坑是把技术债当研发单方面的事
很多团队一提到技术债，就默认是研发的锅——当初写代码的时候图快，现在要自己擦屁股。产品和业务方根本不关心，排期会上只要看到研发要花时间重构，第一反应就是“这部分不产生业务价值，不如多做两个新功能”。
这逻辑真的站不住脚。
技术债从一开始就不是研发单方面造成的。当初要赶618上线，产品说必须两周内出demo，运营说错过节点要损失几百万，研发才不得不写那些临时凑数的代码。凭什么现在要还的时候，全是研发的责任？
之前有个产品经理在排期会上跟老周拍桌子，说你们研发花时间重构，就是不创造价值。老周当场把过去半年的技术债成本看板投在大屏幕上：这半年因为没还的债，研发多花了42人天做重复开发，线上故障损失了近40万的流水，算下来抵得上两个初级研发一整年的产出。那个产品经理当场就不说话了。
其实技术债从来不是什么洪水猛兽。就像你贷款买房子，只要每个月的还款额在你承受范围内，甚至能帮你提前拿到房子住，根本不是坏事。
最怕的是你连自己欠了多少债都算不清，也不知道每个月该还多少，等利滚利到根本还不起的时候，再想救就晚了。
老周现在每个月的部门例会上，第一件事就是把技术债的成本看板投在大屏幕上。所有人都能看到这个月因为技术债多花了多少时间，少赚了多少钱。现在再也没人随便提“以后再重构”的话了——毕竟大家都是出来干活的，对数字，总比对空泛的道理敏感。