代码能跑就别乱动？这话不全对。但半夜四点爬起来重写公司已经付过钱的代码，这事儿我干过。那时候我觉得CakePHP写的项目看着就碍眼，非要用Laravel重写一遍，结果功能一模一样，用户没感觉，速度没变快，就我自己心里舒坦了。后来我才想明白，这波操作纯粹是自我满足。很多重写项目都是这样，满足的是程序员的求知欲、审美洁癖或者面试时能吹的牛皮，而不是公司真正的需求。
能跑的代码是前人踩坑的血泪账本
你想啊，一套代码在生产环境跑了好几年，那可不是简单的几行字母。它是一本活生生的账本，上面记着每一个曾经出现过的bug，还有前辈们是怎么悄悄把它摁死的。
你看到某个地方有个奇怪的if判断，或者一个超时时间设得特别长，八成不是程序员手抖。那可能是当年某个凌晨三点，系统突然崩溃，某个倒霉蛋熬了个通宵才加上的补丁。每一个奇怪的写法背后，可能都有一段惊心动魄的线上事故回忆。
Joel Spolsky早在2000年就说过，重写是软件公司能犯的最蠢的战略错误之一。
把旧代码扔掉，等于把那些修复记录也一起扔了。
然后呢？你会重新踩进同一个坑里，当着同一批用户的面，系统再次挂掉。那些陈年bug就像老房子的蟑螂，你以为拆了重建就没了，其实它们只是躲起来了，等你新装修好，它们又排着队出来遛弯。
我曾经维护过一个十多年的Perl系统，还有一个差不多年纪的自制PHP CMS。那代码长得，说实话，我看了想吐。要是让我现在重新写，我能写出花来。但它们就是稳，稳稳当当跑了那么多年。公司也没想着给它们翻新，这决定太对了。这些代码早就把开发成本赚回来了，每多平稳运行一天，都是纯利润。
看不顺眼不等于它真的坏了
回头看我自己那个重写的例子，我犯的最大的错就是，我压根没认真学过CakePHP。我只是看着它不顺眼，觉得它写法跟我习惯的不一样，就认定它是错的。
这种心态太常见了。当你不太了解一个工具的时候，用这个工具写出来的任何东西在你眼里都是垃圾。因为你还不理解人家为什么要那么写。那种“这写的全不对”的感觉，很多时候只是你还没搞懂而已。
下次再想骂前任代码写得烂的时候，先停一下，反过来想想：之前的程序员不是傻子。他们当时面临的需求、工期、各种限制条件，可能跟你现在完全不一样。代码长成那个样子，一定是有原因的，只不过那个原因你现在看不到了而已。
比如那个奇怪的超时设置，可能当时服务器性能就那样，不设长点就老超时。那个看起来多余的查询，可能当时数据库索引没建好，只能这么绕一下。都是被现实逼出来的智慧。
什么情况下动手重写才算理智
当然不是说什么代码都不能动。要是真这么想，那2026年你还在用没安全补丁的远古版本系统跑业务，那也太离谱了。有些技术债，拖久了是真的会爆雷的。
有几个硬指标，能帮你判断到底该不该动手重写。
第一个，你用的运行环境或者核心依赖库已经彻底没人维护了，而且还有没打补丁的安全漏洞，想升级都升不上去。这种属于等死，必须得动。
第二个，整个系统就一个人能看懂，而这个人刚刚递了辞职信。这属于知识垄断，一旦人走了，系统就成黑盒了，出点事谁都搞不定。
第三个，每次加一个新功能，都要花三倍于正常的时间，因为代码结构太烂了，而且你有数据能证明这个趋势。比如去年加个功能要两天，今年同样的功能要六天，明年可能就要十八天了。这种属于慢性病，不动会越来越疼。
第四个，也是我现在正在经历的情况，业务长太大了，现在的代码架构根本撑不住新的需求。代码本身没毛病，跑得挺好，但业务已经超出了它的设计范围。就像你骑个小电驴在小区里溜达没问题，但现在要你上高速跑长途，那确实得换辆车了。
我现在就在重写一个服务，还用AI编程助手帮了大忙。因为我们要让它干一件它当初根本没设计过的活儿。这种重写是有明确数字支撑的。
所以判断一个重写到底是不是自嗨，标准特别简单：你能算出它带来的具体损失吗？安全漏洞算一个，效率下降算一个，留不住人算一个，错失市场机会算一个。如果算不出具体数字，那你纯粹就是在折腾，就只是个人审美偏好而已。
AI让重写变得便宜了，但该掉的坑一个都不会少
现在有了AI，很多人说重写变便宜了。让AI帮你把一个模块从旧框架翻译成新框架，一下午搞定。但问题在于，写代码从来就不是重写里最花钱的部分。真正的成本在于，你要重新搞清楚当年为什么要那么写。
AI能飞快地生成新代码，但它不知道那个奇怪的超时时间为什么存在。因为这个原因可能藏在2021年某个Slack聊天记录里，或者一个没人想起来链接到源代码的事故报告里。所以AI会给你生成一份干干净净、看起来很合理的代码，把那些老补丁全扔了。你高高兴兴上线，然后跟当年的bug重新打一遍交道，而且这次你连当初人家是怎么修好的都不知道。
更扎心的是，今天你觉得AI写得挺漂亮的代码，过两年也会变成别人眼里的垃圾。因为它也要开始跟现实世界打交道了，慢慢也会长出各种奇怪的补丁和疤痕。然后又一个程序员打开它，看不懂，觉得写得太烂了，于是又想重写一遍。
AI只是让启动重写这个动作变得更轻松了，就像手机下单一样容易。但它并没有打破那个“重写-后悔-再重写”的死循环。真正能打破循环的，是把那些决策的理由用简单的语言写下来。让下一个人，或者下一个AI，知道为什么要这么干，而不仅仅知道干了什么。
所以啊，在你决定重写一套跑得好好的系统之前，先去找到那个数字。那个能证明不改就会出事的数字。如果你找不到，那真正需要维护的，是你那颗躁动的心，而不是那几万行代码。
总结：我们总是高估新代码的美，低估旧代码的好。那些疤痕和古怪写法，都是它活下来的证据。
原文作者：Anatoliy Babushka，资深软件架构师，曾就职于多家科技公司，长期关注工程效率与组织行为。