凌晨两点，工位只剩零星灯光，我对着屏幕上一段三百行的臃肿函数久久发呆。

git blame 的记录直白又扎心：提交人是两年前的自己。当年赶迭代、抢上线，匆匆敲下一行注释： // TODO: 临时方案，后续重构。

可职场里最骗人的两个字，就是「后续」。这个随口定下的优化计划，一拖就是两年，曾经的权宜之计，彻底变成了如今无人敢动的屎山代码。

这种场景，每一个老程序员都不会陌生。我们总在吐槽项目代码混乱、维护成本极高，却常常忽略一个真相：绝大多数让人头疼的技术债，都是我们自己为了一时省事，亲手埋下的伏笔。

技术债从不是单纯的「代码写得烂」，它的本质是一场透支：用未来的迭代时间、运维成本、修复精力，为当下的开发便利买单。更残酷的是，技术债的利息永远是复利，拖延越久，偿还的代价越大。

1. 过度炫技的无效抽象

很多人刚吃透设计模式、掌握架构思想，就忍不住陷入「为了设计而设计」的误区。哪怕只是一段简单的业务判断 if-else，也要强行封装策略工厂、叠加多层继承。

原本十行代码能搞定的逻辑，硬生生拆出七八个类。新同事接手项目，顺着代码层级逐层追溯，绕遍整个继承链，都找不到核心执行逻辑。

2. 静默吞错的异常处理

几乎每个开发者都写过这样的“懒人代码”：

try {
    // 关键业务逻辑
} catch (Exception e) {
    log.error("出错了", e);
    // 静默兜底，不阻断流程
}

看似完美兜底、不影响主线流程，实则是生产环境的巨大隐患。粗暴捕获所有异常、无区分兜底、无告警触发，让很多隐性bug悄悄被吞。线上数据异常、用户反馈报错，监控大盘却毫无预警——这种沉默的容错，本质上是在监控系统里 人为制造灵异事件，排查问题时无从下手，只能熬夜逐行复盘。

3. 投机取巧的假性复用

一次复制是高效，两次复制是将就，三次复制以上，就是典型的技术负债。很多看似相似的业务逻辑，只是表层重合，底层规则、边界条件早已截然不同。

拒绝抽象、盲目拷贝，会导致代码冗余臃肿，后续业务迭代时，需要同步修改多处相似代码，稍有疏漏就会出现逻辑不一致的bug，大幅增加迭代风险。

4. 自欺欺人的注释谎言

// 这里不会返回null
return getMaybeNullResult();

注释是写给人看的，编译器不会识别、不会校验。当初想当然的判断，随着业务迭代、接口更新，早已失效。

聊了这么多技术债，其实想说：清理技术债，从来不是靠一次性大规模重构。

很多团队陷入误区，要么一味赶需求、完全忽视代码质量，要么想一蹴而就重写全部代码，最终导致业务停滞、迭代崩盘。

真正成熟的工程思维，是接纳技术债的存在，把还债纳入常态化迭代。 每个版本预留15%-20%的时间，针对性优化烂代码、修复隐性问题、优化冗余逻辑。不用追求一次清零，只要持续精进、稳步优化，就是最好的工程迭代。

入行越久，越笃定一个道理： 程序员的核心能力，从不是顺风顺水的功能开发，而是对边界条件的敬畏、对代码质量的坚守、对长期工程的考量。

认真处理每一处异常、耐心打磨每一个接口、严谨斟酌每一次命名、主动优化每一段冗余代码。这些看似微不足道的细节，短期看不出差距，但拉长到三五年，就是普通开发者和资深工程师的核心鸿沟。