代码能跑就不要动，程序员都坚持这个观点，45岁老程序说出了真相

导语

新来的程序员小王，看了项目的代码后，觉得老代码内存释放那块设计的不合理。这小伙也挺勤快，他首先想到的是重构代码，然后他模块化了内存释放的那块逻辑，代码看起来更方便读，然后没过几天，生产上出现了重大事故，经过排查就是这个内存释放的优化，有个位置漏了.然后导致了损失了几千万。

动不动改代码会发生什么事

旧的代码有的时候会不写注释，不写设计文档，你不知道这些代码埋了什么坑，尤其对于新来的人，根本看不懂，想改代码基本上不可能，只能考虑重构，但是重构的成本太高，一般公司都不允许你去重构。所以你去改代码，可能会出现其它问题，有的时候会产生重大bug，造成公司的经济损失。

并且你改了别人写的代码，虽然短时间看事完成了任务，代码改的很完美，领导也只会认为这些应该是你做的，而且一旦出问题，责任就是你，劝退或者扣工资，扣绩效。也就说掏力不落好。除非你背后有靠山，比如你老爸就是老总，你可以随便改。

这本身不是一个技术问题，随便改代码可能上升到政治问题，你改的代码谁来背锅，你出错的成本和受到的惩罚根本不成比例。

代码修改需要遵循什么规则

open/close 原则：首先在线上跑的代码是最经过验证的，怎样安全地修改这些代码呢，open/close 原则的建议是使代码能够 open for extension / close for modification，因为 modification 很容易踩到现有代码未知领域里的细节行为问题，但 extension 因为是新代码没有历史包袱，是容易理解和测试的。

第一法则：如果你的代码以某种方式跑了起来，无论如何莫名其妙，请你不要再碰它了。

怎么更优雅的改代码

老代码就不可以动了吗？肯定不是，代码是遵循不断迭代更新的，所以老代码最终将面临修改。那么怎么改呢？当然不是我们无脑的看到不好的代码就去改，而是要遵循一定的技巧。

从领导进行，和领导沟通让其投入资源支持我们的重构，包括配套的测试、灰度、责任分担机制等。但是如果领导不配合，你可以放大老代码的漏洞，你试图在测试环境触发这个漏洞，然后让测试提出，很完美的把锅推给了之前的开发。