【导语一位程序员自发将公司的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很重要有测试套件是重构的前提凌晨四点自发改代码要问问自己是帮公司还是满足自己。编辑观点此次讨论反映出代码重写需综合考量业务需求、技术水平和测试保障等因素盲目重写不可取应在充分评估后谨慎行动。
