越拖越贵的代码欠条 技术债

上周在河西万达旁边的鸭血粉丝汤店碰到老周，他刚从公司逃出来，衬衫袖子挽到胳膊肘，手里攥的半瓶冰红茶都被捏变形了。他说上周排的电商大促预热需求，本来3天就能上线的活动页，硬生生卡了7天。原因说出来有点好笑——翻旧代码的时候发现，三年前的前端写的用户鉴权逻辑，连半行注释都没有，函数名全是a()b()，改一行要蹦三个报错，没人敢动。他说这就是他们组还了三年还没还完的账。

不是所有的“旧代码”都叫技术债

很多人一开始对技术债的误解，就是把所有跑了很久的老代码都归为需要被彻底推翻的存在，却忘了那些经过无数线上流量验证、逻辑边界清晰、哪怕写得再朴素的代码，其实是整个系统最稳的压舱石。真正的技术债从来不是“代码老”，而是当初为了省时间走的那些“没人兜底的捷径”——为了赶版本跳过的参数校验，把同一段逻辑复制粘贴了五六份到不同的页面，本该写的单元测试省得一干二净，甚至为了快速上线，把用户的敏感信息明文存在前端缓存里。这些操作当时省了多少时间，后来就要花十倍甚至几十倍的时间去填坑。 说实话，我之前也见过不少团队，一提到技术债就如临大敌，非要把所有老代码全推翻重写，最后折腾了三个月，新bug比旧代码还多，何苦呢？

没人愿意当那个“拆东墙”的人

为啥这些捷径会变成还不清的债？核心原因根本不是工程师懒，是没有即时业务反馈的技术债偿还，永远会被排在需求优先级的最末尾。 老周说他们之前试过专门抽两个工程师，花一周时间重构那个乱成一锅粥的用户鉴权模块，结果季度复盘的时候，领导第一句话就是“这一周你们没产出任何面向用户的东西，绩效怎么算？”。谁愿意干这种吃力不讨好的事啊？你把代码改得结构清晰了，用户感知不到，业务转化率也不会立刻涨一个百分点，反而要是重构的时候没兜住边界，出了线上故障，那锅结结实实扣在你头上。 上次他们第一次尝试重构那个鉴权逻辑，刚上线半小时就有三个老用户反馈登不上系统。查了半天才发现，当初写代码的同事为了方便内测，在判断逻辑的最后藏了个针对特定测试账号的白名单分支，没写任何注释，连提交记录里都只写了个“临时调整”。那时候整个开发群都在刷捂脸的表情，老周说他盯着监控屏幕，连灌了三杯冰美式，手心全是汗。 不过话说回来，换你是业务负责人，你愿意把本来能用来做新功能的人力，抽去改那些用户根本看不见的代码吗？对吧，换谁都要算算账。

还技术债根本不用“大动干戈”

很多人对还技术债的想象，就是要专门搞个“重构冲刺周”，停掉所有新需求，全组人关在会议室里花一个月改代码。这种操作别说业务方不同意，就算同意了，最后大概率也会变成为了重构而重构，根本解决不了实际问题。 老周他们后来摸索出来的方法，就特别实在。不需要专门停掉业务去搞“运动式重构”，每次碰到涉及旧模块的需求，必须抽20%的时间，把碰到的那部分烂代码顺手收拾了。比如这次要改活动页的登录逻辑，那就顺便把当初那个叫a()的函数改成有实际语义的命名，把复制粘贴了三遍的参数校验逻辑抽成公共方法，不要等下次再有人踩同样的坑。 他们还建了个专门的技术债清单，每一笔都标清楚“欠了多少利息”——比如这个模块如果不重构，下次改类似需求要多花3天的开发时间；那个接口如果不做限流优化，大促的时候可能扛不住1万的并发流量。每次开需求评审会的时候，就把这些清单摆出来，不是说我们不做新功能，而是要让所有人都算明白，现在接这个需求，我们要额外多花多少时间填之前的坑，不是工程师故意找事，是这些债真的会拖慢整个项目的速度。 上周再跟老周约鸭血粉丝汤，他衬衫袖子没挽那么高了，手里的冰红茶也没被捏得皱巴巴。他说现在他们组每个迭代都会留15%的时间，专门处理清单上优先级最高的技术债。当然，新的技术债还是会产生——毕竟哪个团队赶版本的时候没点临时抱佛脚的操作？但至少现在，没人再对着三年前的旧代码骂娘了。 上次他们把那个藏在角落里的白名单逻辑补上注释之后，新来的实习生第一次改那个模块，居然只花了半天就搞定了，当时整个组都在群里发小红包。 谁没赶过急单啊？ 哪个团队上线第一个版本的时候，没点临时凑出来的逻辑？ 技术债从来不是什么洪水猛兽，就像你赶时间出门的时候忘了倒垃圾，晚个一两天也没关系——但你要是一直堆在角落不管，哪天招了虫子，耽误的全是自己的生活。