有个程序员凌晨四点爬起来，连续好几周，把公司一个跑得好好的 CakePHP 应用重写成了 Laravel。没人让他干，他自己想干——因为他"不太懂 CakePHP，看每个文件都觉得不对"，而 Laravel 用着顺手。

重写完以后：功能一样，速度一样，用户完全没感觉。

他把这件事写成了一篇博客，发到 HN 上以后，58 个赞，49 条评论，引起了一场关于"重写到底为了谁"的深度讨论。

原帖作者 bbsnly 的自我检讨很坦诚："我当时对 CakePHP 几乎一窍不通，所以看哪都不顺眼。我爱用 Laravel，所以我想用 Laravel 重写。结果是零业务收益。"但他可能没想到的是，评论区并没有一边倒地支持他的结论。

点赞最高的一条评论来自 Twey。他说了一句不好翻译但很精准的话："一个资深工程师很大一部分（且越来越大的）价值，就是他的 taste。"有时候工程师没法完全说清楚为什么现有代码不对——他们是在用自己见过的大量失败案例做模式匹配。这种直觉不应该被简单地归类为"技术偏好"。

但这个观点立刻被反驳了。jghn 说："只有在工程师的激励和业务激励对齐的时候才成立。但事实远非总是如此。"dude250711 补了一刀：做重写的人经常"用它来美化简历，然后跳槽走人，让别人收拾残局。"

如果说原帖作者的自我批评太温和，那 malux85 就是另一个极端。他的立场是：拒绝学习现有技术栈是"强烈的负面信号"，足以成为开除的理由——"大规模重构的第一步，是理解并胜任现有系统。"

但最有信息量的讨论，来自那些试图把"重写"这个词拆开的人。

dkarl 做了一个关键区分：重写（rewrite）和重新架构（re-architecture）是两回事。很多时候"现有系统可以继续做它该做的事，只是架构环境发生了变化"，或者"90% 的代码可以不变"，只改应用容器的部分。他还指出了一个常见的陷阱：声称需要重写的人，往往只是"拒绝去学现有的语言、框架或持久化技术"。atq2119 引用了 Kent Beck 的名言："先把改动变简单，再做这个改动。"

评论区大约有四分之一的人不同意原帖的前提。darth_avocado 指出，大多数重写不是从"我不喜欢这个框架"开始的，而是从"缺少功能、框架过时、维护困难、成本问题、扩展性瓶颈、合规要求"开始的——这些都是服务于业务的。

argee 是亚马逊的早期员工。他回忆说，亚马逊的渲染引擎被重写了三次，"每次都解锁了新的生产力层级。没有这些重写，网站会慢到爬不动，公司大概率已经死了。"但他的同事 cadamsdotcom 补充了一个关键前提：亚马逊有强大的端到端测试套件，"有这个，你可以随意重构和重写。"

也有人对原帖作者的遭遇感同身受。mcv 说："我以前总假设前辈比我懂。后来发现，我错了很多次。"dijksterhuis 给了一个案例：他接手了一个系统，前任团队留下了"遍地 bug、竞态条件、前端崩溃、数据丢失、自研的安全方案"，结论是"他们真的搞砸了。"他给这场讨论贡献了最精辟的一句总结："好的重写是好的，坏的重写是坏的。你只有在开始以后，才知道自己做的是哪一种。"

watwut 给出了全场最让人会心一笑的评论："如果你凌晨四点就起来干这个，到第二天你就已经睡眠不足了，所以没法阻止自己干蠢事。"

49 条评论，没有得出一个简单的答案。但有一些共识浮现了出来：不懂现有系统就别谈重写；区分 rewrite 和 re-architecture 很重要；有测试套件是重构的前提。以及，如果你凌晨四点爬起来改代码而没有人要求你这么干，至少问自己一句：我到底是在帮助公司，还是在满足自己。

参考来源：

• https://news.ycombinator.com/item?id=48750934
• https://anatoliybabushka.com/blog/when-to-rewrite-working-code.html