程序员凌晨4点重写代码引热议：重写到底为了谁？

【导语：一位程序员自发将公司的CakePHP应用重写成Laravel，却无业务收益，此事在网上引发了关于“重写到底为了谁”的深度讨论，评论众多且观点不一。】

程序员自发重写代码，零业务收益引讨论

有程序员凌晨四点爬起来，连续好几周，将公司运行良好的CakePHP应用重写成了Laravel。这一行为完全是他自发的，原因是他“不太懂CakePHP，看每个文件都觉得不对”，而Laravel用着顺手。但重写完后，功能和速度都与之前一样，用户完全没感觉。他把这件事写成博客发到HN上，获得58个赞、49条评论，引发了关于“重写到底为了谁”的讨论。

评论区观点碰撞，重写动机引争议

原帖作者坦诚自我检讨，称“对CakePHP几乎一窍不通，重写零业务收益”。然而评论区并未一边倒地支持他的结论。点赞最高的Twey认为，资深工程师的一部分价值在于“taste”，他们的直觉不能简单归为“技术偏好”。但此观点立刻被反驳，jghn指出只有工程师激励和业务激励对齐时才成立，dude250711更是指出做重写的人常“用它来美化简历，然后跳槽走人，让别人收拾残局”。

malux85则认为拒绝学习现有技术栈是“强烈的负面信号”，足以成为开除的理由。而darth_avocado指出，大多数重写是从“缺少功能、框架过时、维护困难、成本问题、扩展性瓶颈、合规要求”等服务于业务的因素开始的。

区分重写与重新架构，测试套件成关键

dkarl做出关键区分，认为“重写（rewrite）和重新架构（re - architecture）”是两回事，很多时候现有系统只需改变架构环境或只改应用容器部分，而声称需要重写的人往往是“拒绝去学现有的语言、框架或持久化技术”。atq2119引用Kent Beck的名言“先把改动变简单，再做这个改动”。

argee回忆亚马逊渲染引擎重写三次解锁新生产力层级，但同事cadamsdotcom补充关键前提，即亚马逊有强大的端到端测试套件，有这个才能随意重构和重写。

重写好坏难断，达成部分共识

有人对原帖作者的遭遇感同身受，mcv表示以前总假设前辈比自己懂，后来发现错了很多次；dijksterhuis接手系统后发现前任团队留下诸多问题，总结“好的重写是好的，坏的重写是坏的，开始后才知道是哪一种”。

49条评论虽未得出简单答案，但达成了一些共识：不懂现有系统就别谈重写；区分rewrite和re - architecture很重要；有测试套件是重构的前提；凌晨四点自发改代码，要问问自己是帮公司还是满足自己。

编辑观点：此次讨论反映出代码重写需综合考量业务需求、技术水平和测试保障等因素，盲目重写不可取，应在充分评估后谨慎行动。