上周在南京河西的产业园楼下喝冰美式，碰到之前在电商公司共事的老周。他把印着程序猿头像的电脑包往桌上一甩，开口第一句就是“我这季度的绩效要被技术债吃没了”。
我当时喝了一口冰美式差点呛到。说你这哪是绩效被吃，你这是三年前为了赶618大促KPI挖的坑，现在轮到你掉进去了。
你以为的技术债，和真实的技术债根本不是一回事
很多人对技术债的理解还停留在“代码写得烂”的层面，比如缩进不统一、变量名起得像乱码、注释全是“TODO”。说真的，这些都是小毛病，连债的门槛都摸不到。
真正能把人逼到崩溃的技术债，是当年为了赶上线，主动砍掉的架构设计、省掉的校验逻辑、绕开的性能优化——这些东西在上线当时全是“正确选择”，毕竟业务方要的就是三天后能跑通的功能，谁管你半年后会不会出问题？
老周他们当年为了扛618的瞬时流量，把本来要做的异步下单流程直接改成了同步接口，连最基础的参数校验都没加，当时确实扛住了每秒两万的请求量，运营那边的战报刷了满屏的喜报。结果呢？现在每次要加个新的优惠券规则，都要翻三四个嵌套了七八层的if else，改一行代码要测全链路的十几个场景，上个月光因为这个接口的逻辑bug，就赔了用户三万多的优惠券。
技术债最坑的地方，是它根本不会写在你的需求文档里
没人会在需求评审会上跟你说“这次我们要故意留个坑，半年后让后面的人擦屁股”。所有人当时的理由都冠冕堂皇：“先上线跑起来，后面再优化”“这个功能是临时的，下个月就下线”“流量没那么大，不用做那么复杂的设计”。
结果呢？临时功能用了三年都没下线，当年拍胸脯说要负责优化的人早就离职去隔壁拿翻倍工资了，剩下的人每次做新需求，都只能在原来的烂逻辑上再加一层补丁，就像老破小的墙上打了十几个钉子，挂了十几根晾衣绳，风一吹整个墙都在晃。
老周现在管的下单接口，光入参就有37个，其中12个是后来不同业务场景加的特殊规则，传参的时候只要漏了一个，系统就会自动给用户发100块的无门槛券。上个月已经出了三次这个事，运营过来骂，财务过来找，没人敢动那个接口——谁改谁背锅，改出问题是你的，改不好耽误新功能上线也是你的。
还债从来不是某几个程序员的事
真的别再跟我说什么“程序员要对自己的代码负责”这种屁话。当年为了赶上线熬了三个通宵把代码怼上去的人走了，现在留下来擦屁股的人，凭什么要替他背所有的锅？
我之前待过的南京本地生活团队，处理技术债的方式就很务实。每次做新需求的时候，允许开发拿出15%的时间，顺手清理当前需求涉及模块的坑——比如这次要改优惠券的逻辑，就顺手把原来嵌套的if else拆成独立的方法，把那个容易漏传的参数加上校验，不追求一次性把整个系统重构完，每次动一点，积少成多。
还有个很重要的原则：不是所有的技术债都值得还。那个下个月就要下线的活动页面，代码烂到天上去也没关系，反正没人用了，没必要浪费时间去重构。那些已经跑了好几年、从来没出过问题的老模块，也没必要没事就拿出来重构，万一改出问题反而得不偿失。
老周上周回去跟业务老大提了个方案，接下来三个月，每个新需求的排期都多留10%的时间，用来清当前模块的债。业务老大一开始不同意，直到老周把上个月三次发错优惠券的损失算出来——小十万，当场就拍板说行，就按你说的来。
债这种东西。
你不主动还。
它迟早会把你拖下水。