重构的诱惑：一个前端工程师的自我批判
每个工程师心里都住着一个重写的魔鬼。它在你读烂代码读到第七百行的时候出现，在你接手别人项目的第一周出现，在你看到新框架发布会的第一个夜晚出现。它说话的声音永远温柔：「推倒重来吧，这次我们一定设计好。」
我听过它的话。三次。第一次，我把一个运营了两年的活动页系统重写成「现代架构」，上线当天性能反而劣化——旧系统烂，但它烂得很有经验，每一个丑陋的补丁都对应着一个真实的生产事故。重写之后，事故以新的形式回来了，而我甚至没有旧补丁的记忆加成。第二次，我在一个五个人的团队里推动「统一技术栈」，两个月后统一完成了，业务进度归零，两个同事离职了。第三次最荒诞：我把一个能跑的后台重写成更漂亮的版本，然后老板问新功能什么时候上——我说在重构。他说：用户看得到重构吗？
这不是说重构没有价值。价值在于区分两种重构：一种是「还债型」，代码已经阻碍交付，每一行都在消耗团队的心智，不重构成本只会复利增长；另一种是「美学型」，代码能跑、能交付、只是不符合你的审美。还债型重构要算账：这债的利息是多少（每次改动的额外工时、事故率、新人上手时间），重构本金是多少，多久回本。美学型重构没有账可算，因为它不产生现金流，只产生快感。
魔鬼最狡猾的话术是「现在不重构，以后更难」。这话九成时间是假的。代码不会自己变难，变难的是需求和人的记忆；而一个能持续交付的烂系统，健康程度远超一个停在重写中途的好系统。行业里死于「重写未遂」的项目，远多于死于「技术债」的项目——前者死于失血，后者只是带病生存。
我的处方是三问：这次重构能让下一个需求变快多少？如果不做，六个月后最痛的场景是什么？能不能只重构要改的那百分之十？第三问是解药。局部重构、伴随需求重构、重构跟着交付走——把重构筑进业务的车轮里，而不是让它单独上路。单独上路的重构，叫旅行；没人付旅费。
至于心里那个魔鬼，不必驱逐，给它发工资就好：每周留半天，整理一小块最痛的代码。它有了固定收入，就不惦记倾家荡产的大买卖了。
「旧系统烂得很有经验」——每个丑陋补丁背后都有一次真实事故，这句该写进所有重构文档首页。
三问里的第三问是关键：跟着需求做局部重构，债就还在了刀刃上。
「给魔鬼发工资」这个比喻可以进教材。每周半天，积小胜。
作者回：三次重写教训，学费比任何课程都贵。写出来就是想让大家省这笔。