接手老旧项目，真想一把推倒重写？聊聊程序员的执念与现实

那天，我接到一个任务：去维护一份饱经风霜的老项目。  

下载代码后，项目的前同事告诉我：这是老系统，目前“非常稳定”，但任何改动务必小心、小心、再小心！  

可代码还没看几行，一个念头就不自觉地冒了出来——作为一名软件工程师，如果把它铲为平地，由我重新设计，选用最新的技术栈，重建一套漂漂亮亮的新世界……  

这该是一件多么美好的事！  

但说到底，为什么面对老旧项目，程序员们总是“一言不合就想重写”？很大程度上，是因为读旧代码——尤其是又老、又长、又乱的代码——实在太痛苦了。  

为了赶 deadline，或者因为当年的业务野蛮生长，许多老项目里一个函数就能带几十个参数，逻辑绕了上千行。光是厘清这些堆叠了无数补丁的“屎山”，就足以让人抓狂。更别提那些早已过时的技术栈，对个人成长几乎没有任何帮助——我们自己才是工程的主人，谁又愿意一辈子在别人的代码上缝缝补补呢？  

而且程序员常常太过乐观。我们只看到了维护老旧项目有多烦，却很容易忽视推倒重写背后的巨大风险。  

新写的代码就真的一定比老代码好吗？至少老代码还在线上跑着，扛住了无数真实的流量。时间是否允许？几时能够上线？资金是否足够？……还有，老板同意了吗？  

说到底，重构从来不是纯粹的技术决策，而是一场团队、业务、时间与成本的平衡。当那种“干脆全部重来”的冲动再次涌上心头，不妨先冷静下来，去云栈社区看看同行的经历，或许你能找到更务实的破局之道。