上个月在南京新城科技园，一个做 SaaS 的团队拉我去看订单系统。需求很小：改运费模板。结果排期三天。不是开发慢。是没人敢动那段代码。
五年前为了赶大促，运费计算被写成一串 if-else。后来加渠道、加区域、加会员等级、加偏远地区。现在文件里 47 个分支。注释比代码还老。这就是技术债。它不是欠银行钱，是欠未来的自己一个解释。每次需求来，先还利息。很烦。
技术债不是烂代码是决策的利息
很多人把技术债当脏话。说实话，不对。技术债是当时为了更快、更省、更稳，选了一条捷径。外包赶工、没有测试、硬编码、跳过评审。都算。问题不在借，在于不记账。你不知道本金多少，利率多少。有人借了五万，三年后利息五十万。团队每天都在还。
不过话说回来，零技术债的团队我没见过。见过的是把债写在墙上，按季度还。也见过把债藏在“祖传代码”里，谁碰谁背锅。差别很大。
最贵的技术债往往不在代码里
代码债看得见。流程债、架构债、测试债，更阴。流程债是只有某个人知道怎么发版。他一休假，线上出事，群里刷“谁记得那个脚本”。架构债是单体数据库所有模块共用一张用户表。字段不敢删，索引不敢动。测试债是回归靠点点点，点完还要烧香。
这些债不冒烟。但它们吃人。吃的是变更速度，吃的是新人信心。对吧。
还债别搞运动式重构
我见过最惨的还债，是老板喊一句“重构”。三个月后，分支合不回去，需求全停，线上炸两次。团队士气归零。技术债没还完，又借了高利贷。
务实点。先找最疼且可逆的点。别一上来微服务。可以这么做：给旧逻辑加日志，量出哪些分支真在跑；写契约测试，把外部依赖钉住；用绞杀者模式，新需求走新路径，老路径慢慢饿死；每周留半天，固定还债，叫架构健康日也行；用指标说话，变更前置时间、失败率、恢复时间。老板不听“优雅”，听“这次大促能省三台机器”。
别骂前人。有天你也是前人。真的。
行动清单能明天开始的那种
- 把最痛模块的变更时间记下来。先有数。
- 给最常改的文件加测试。别追求覆盖率，追求敢改。
- 把隐式知识写成 runbook，扔进仓库。谁都能看。
- 每次需求附带 10% 还债预算，写进排期。不然永远没空。
- 每季度挑一个债，公开还。还完写一页复盘。别长。
技术债擦不完。像厨房油烟。但只要你知道哪根管子漏，哪块墙皮鼓，就不至于淹了灶台。回南京的路上我想，团队怕的不是债。是不知道债在哪。对吧。