大楼加楼层加到一定高度会塌,这是常识。代码没有这条底线——只要还能跑,它就能一直烂下去。这句话出自工程师Zach Kehs两天前的一篇博文,被Simon Willison摘录转发,听起来像一句职场吐槽,但它在Hacker News和Reddit上掀起的讨论,比这句话本身有意思得多。
一句箴言背后的真实战场
Kehs的原文举了一个例子:某大型电商的订单处理系统庞大到没人能完全理解,里面留着大量没有文档的规则,工程师碰都不敢碰,他称之为"闹鬼的墓地"。他的核心论点是,重写解决不了这个问题——因为旧系统在迁移期间必须继续运行,你没法真正把债务清零,只能背着新旧两套系统一起走。
这篇文章截至Willison转发时,在Hacker News积累了约98个赞、77条评论,Reddit上也有多个帖子跟进讨论。一句吐槽能吵到这个规模,说明它戳中的是普遍痛点,不是个案抱怨。
Reddit上有工程师分享了更极端的案例:维护着十几万行1970年代的FORTRAN代码,没有注释,没有子程序,变量名只有四个字符——这套系统仍然每天在跑。这不是理论,是很多老牌公司IT部门的日常。
吵的其实不是"代码会不会烂"
细看争论内容,分歧点比想象中窄。HN上最有力的反驳不是否认代码会腐化,而是质疑Kehs"没有任何重置可能"这句话说得太绝对——报废一个系统、下线它、换成供应商产品,本身就是一种技术破产,只是很多公司不愿意付这个代价。
Reddit上一个案例把这个矛盾具象化了:某大型机迁移项目里,负责替换旧接口的团队,速度追不上另一边COBOL团队新建接口的速度——迁移在原地打转,甚至倒退。有人把这种现象叫"负进度"。清理的速度追不上制造的速度,债务只会越滚越大。
- 结论.代码的终点不在代码本身,而在组织愿不愿意为报废和重写这两个字买单。
这场辩论里还冒出一个原文完全没提的角度:亚马逊这类大厂容忍内部系统"带病运行",未必是管理失控,更可能是一种主动选择——先抢市场份额,拿质量换速度,清理债务这件事被排到了商业优先级更靠后的位置。如果这个判断成立,技术债就不完全是技术问题,而是一次公司层面的博弈结果,只是账最后落在了工程师头上。
AI会不会打破这个死循环
两个社区都出现了明显的意见分裂。一部分人认为,现在的大模型特别擅长读懂遗留代码、补测试、辅助重构,可能第一次让"清理"的速度有机会追上"制造"的速度。另一部分人的判断更冷:工具解决不了组织的激励问题,团队所有权碎片化、评审缺失这些老毛病不会因为多了个AI助手就消失——AI只会让现有轨迹跑得更快,不管这条轨迹是变干净还是变更烂。
我不太买账"AI会自动修好一切遗留系统"这种乐观叙事。工具能力再强,决定它被用来清理还是被用来堆砌新层的,始终是那个签发预算的人。这跟修一条老铁路没什么本质区别——技术能把轨道铺得更快,但铁轨往哪个方向铺,永远是运营公司算利益账算出来的。
Kehs那句箴言最狠的地方,其实不是"代码没有上限",而是它逼着人承认:没有任何自然力量会让代码变好。物理建筑至少有重力帮你兜底,逼你在倒塌之前动手加固。代码没有这个提醒机制,唯一的刹车,是人愿不愿意主动踩。