上个月去南京河西一家做本地生活的创业公司驻场，刚坐下就看见开发小张盯着屏幕揉眼睛。当天是618大促前最后一天，产品在旁边催得冒烟，要求活动页必须在晚上八点前上线。他图快，把去年写的满减优惠券判断逻辑整段复制过来，连阈值判断里的”满100减20″都没改成”满199减30″。当时测了下单流程能跑通，就点击了上线按钮。
你凑上去的那行野代码
三周后我再去这家公司，小张已经离职了。接手这段代码的开发翻了两个小时才找到那个写错的判断条件——因为当初写的时候连个注释都没有，满屏嵌套的if else，顺着链路捋到一半就绕晕了。光修这个bug就花了整整两个工作日，差点错过双11的预热上线。
说真的，这种事我见得太多了。
没人想故意写烂代码。
deadline压在头上的时候，谁顾得上什么优雅架构、分层设计？能先跑起来，不被老板骂，就是第一优先级。很多人对技术债的误解特别深，总觉得它是资深程序员矫情的产物，是嫌代码写得不够”高级”的挑剔。其实根本不是——大部分技术债从你为了赶进度跳过单测、硬复制粘贴现有逻辑、把本该抽成公共组件的代码在三个页面各写一遍的那一刻，就已经记在账上了。你当时省的那两小时，后面迟早要连本带利还回来。
没人给你算的隐性成本
我之前跟一个做电商的技术负责人算过一笔账。他们公司三年前拿到融资的时候，为了抢本地生活的风口，三个月硬上了五个核心功能。当时老板拍着桌子夸团队效率高，结果呢？现在每次发版，光跑回归测试就要花整整一周，当初图快没做幂等校验的支付模块，光去年一年就出了四次重复扣款的客诉，赔了快二十万。更别说新同事入职，要花整整一个月才能摸清楚那堆绕来绕去的业务逻辑，每次要加新功能，都要先花半天时间跟旧代码”搏斗”。
技术债最坑的地方，是它的利息从来不会在你借的时候提醒你。
它不会直接炸。
它会在你每次要加新功能的时候，悄悄多卡你半小时。
它会在你半夜被运营的电话叫起来改线上bug的时候，把所有你当初省下来的时间，连本带利讨回去。很多团队直到发版频率从每周一次降到每月一次，直到线上bug的数量翻了三倍，直到核心开发离职后没人敢碰老代码，才反应过来——原来当初省的那些时间，早就换成了更高的成本。
别等债台高筑了才想起还债
很多团队一提还技术债，第一反应就是停所有业务，安排两周的”重构专项”，把所有旧代码推翻重写。最后要么是重构到一半被新的业务需求打断，整个项目烂尾在半路上；要么是重写的代码没经过充分测试，上线后出了更多线上问题，团队上下怨声载道。
我见过节奏把控最好的团队，从来不会搞这种”运动式还债”。他们会在每个迭代里留15%的固定容量给技术优化，不是专门抽时间大动干戈，而是每次改到那堆乱麻一样的旧代码时，顺手把涉及到的逻辑理清楚，能补的核心测试用例补上，能抽成公共组件的部分拆出来。之前有个做生鲜配送的团队，之前订单模块的代码乱到没人敢碰，他们没安排专门的重构时间，只是每次改订单相关需求的时候，要求开发多花20%的时间，把碰到的那部分代码顺手整理下。过了半年，整个模块的可维护性提上来了，发版时间从原来的一周一次，变成了一天一次。老板根本没觉得这是在”还技术债”，只觉得最近团队效率高了。
只要那段代码能稳定跑业务，没有增加团队的协作成本，就算写得再朴素，也不算需要急着还的债。 没必要为了追最新的技术框架，把能跑的旧代码全部推翻。
上周跟之前那个写野代码的小张聊天，他现在换了新工作，入职第一天就把项目里重复的逻辑抽成了公共组件。他说现在才明白，当初在老东家偷的那点懒，最后都成了自己简历上不敢提的黑历史。
对吧？谁还没为了赶进度写过两行自己都不想看的代码呢。
真的别把技术债当什么洪水猛兽，也别把它当成程序员甩锅的借口。
它就是一笔普通的账。
你借的时候有多爽，还的时候就有多疼。