上周跟南京做电商SaaS的老周吃饭，他刚为上个月攒的技术债赔了1980块。
真的疼。
当时618大促的预热节点卡得极死，晚一天上线就要少十几万的预估营收，组里三个开发连轴转了36小时，把所有优惠券叠加的判断条件直接写在了请求入口的代码里，连个单独的函数都没封，更别说写注释、补单测。上线那天所有人都盯着后台的流量曲线往上跳，没人记得那堆硬塞在分支判断里的逻辑，满脑子都是终于能回家睡个整觉。
赶版本攒下的债从来不会凭空消失
结果到上周做秋季满减活动，老周让组里的年轻开发改优惠券叠加规则，那小孩翻了三个页面的代码，改完测了半天，还是漏了一个当初藏在if判断里的特殊用户规则——三个高等级用户下单的时候，满减、优惠券、会员折扣叠到了零，平台直接免单。钱赔了不说，还要跟用户来回沟通解释，折腾了整整两天才把问题全部捋顺。
这债，躲不掉的。
你以为当初省下来的半小时封装时间是赚了，实际上后面要花几倍甚至几十倍的时间，为这段没人看得懂的临时代码擦屁股。我见过太多团队赶版本上线的时候，把所有优化、测试、文档的环节全部砍掉，代码里留满了临时的判断逻辑，等下个版本要改相关功能的时候，连当初写这段代码的人自己都记不清当时的逻辑是什么。
大部分技术债根本不是写代码的人故意偷懒
我见过太多人把技术债等同于“代码写得烂”，觉得是开发图省事、不遵守规范才攒下的问题。说穿了，哪有那么多故意写烂代码的傻子，对吧。
很多时候技术债的产生，根本不是个人能力的问题。去年接触过一个做企业服务的小团队，为了抢一个头部客户的年度合同，花了一周时间搭了个能跑通所有演示流程的demo，当时为了让demo跑起来足够快，连数据库的外键约束都没加，所有的查询都没做索引，单表只有几万条测试数据，跑起来丝滑得很，客户看完直接签了三年的合同。结果上线之后，客户的内部数据越攒越多，半年时间单表就涨到了两百万条，之前没加索引的那个查询，每次跑要8秒，赶上客户月底做报表的时候，整个系统直接卡死，客户的信息部打了好几个投诉电话。这时候团队再回去补索引、优化查询，要做数据迁移，要停机维护，前前后后折腾了两周，花的成本比当初一开始就花半小时把索引加上，高了快两百倍。
你说当初他们不知道要加索引吗？当然知道。但当时的优先级是“先把demo跑通，把合同签下来”，所有的优化动作，都给“赶进度拿结果”让了路。技术债从来不是某个人的错，是项目推进过程中必然产生的“时间折现”——你现在少花的那部分优化时间，未来一定会连本带利还回来。
别等债滚成高利贷才想着收拾
说实话，我从来没见过哪个团队能把所有的技术债一次性清完。那不现实。
很多团队一提技术债就头疼，觉得要专门排个迭代周期，停下所有的新需求，花一两个月把所有烂代码全部重构一遍。我见过好几个这么干的团队，重构到一半业务催着上新功能，半拉子的重构代码扔在仓库里，比之前的旧代码还难维护。
真正靠谱的还债方式，根本不是搞什么大规模重构。就像老周他们团队后来做的那样，每次改到跟之前优惠券硬编码相关的需求时，就顺手把用到的那段逻辑抽离成独立的公共方法，改一点抽一点，不专门占项目排期，花了三周时间，就把之前散在各个controller层的优惠券逻辑全部抽完了。现在改新的满减规则，只需要在公共方法里改个参数，十分钟就能搞定，连之前一半的测试时间都用不上。
爽得很。
最划算的还债时机，永远是你第一次接触到这段有问题的代码的时候。不要等这段代码的问题已经影响到线上稳定了，才想着回头收拾。也不要觉得只要现在能跑，以后再说——你永远不知道后面接手这段代码的人，要在多少个加班的深夜，为当初的省事儿买单。
前几天老周跟我说，现在他们团队每次赶版本上线，都会专门留个小任务，把这次赶进度写的临时逻辑记在项目的待办列表里，等下一个迭代的时候顺手优化。毕竟谁也不想，下次再因为之前的偷懒，赔出去小两千的真金白银。