先给大家讲个小故事：

新来的程序员小哥觉得代码不规范，内存释放的模块很混乱。这可能有隐藏的风险。接下来，他做了整合，把内存释放进行了模块化，专门整好了。代码变的更优质了，对吧？到这里算是好的。

然后过几天，就出事了，生产出现重大故障。系统内存泄漏，系统崩了，影响客户使用。客户投诉，扣钱。然后整个项目组开始大排查。排查到最后，就是这个内存释放的优化，有个位置漏了，没改到。但是其他位置全改掉了。然后这个没改到的位置，内存长期不释放。好了，内存爆了，内存泄露，系统崩溃。就是这个优化，导致了重大故障。

然后全公司通报批评。要求项目组整改，并且出检讨，现在能理解了吗。代码能跑，就别改。

本质原因：一个不能动的老代码，代表的是正常工况下正确运行的无风险收益，暗藏项目管理疏漏所导致的潜在危机，是开发者和管理者的失责。

出来行走江湖写代码，最重要的就是两条原则：

1、代码能跑就不要动！

2、祖传代码，不要乱动。。。

按照此原则，长此以往，代码库中会逐渐累积各种技术债和潜在的缺陷。随着时间的推移，重构代码的代价会越来越大，风险也越来越高。这种情况下从风险收益比来看，尽量不要改动能够运行的代码是一种局部最优的策略。

只有当代码质量严重影响了系统的稳定性以后，中层甚至高层管理者才会有动力去投入资源做大范围的重构和改良。而这种时候通常伴随着技术团队人员流动，很容易出现全部推翻重写的局面。

个人认为倒也不是绝对的。这取决于你个人对整个项目的熟悉和理解程度。

可以动的情况如下：

你是项目的主要代码贡献者之一，你对每个模块做什么都有充分的理解，知道修改带来的影响。

项目成败责任在你，你需要判断某个模块如果不修改的风险，以及事故发生时会造成什么损失。

虽然之前的代码很乱但能跑起来，但项目还没上线，为了日后系统的稳健，你决定大动干戈，重构一下。

不要动的情况：

你往一个巨大的项目里面添加了小功能，为小功能而且修改已经存在很久的部分，风险是很大的，除非你有充分的理由。

项目bug很多，改了一个bug会有n个新bug出现。

项目已经上线，如果需要大改动，需要测试

顺便在这里说一下，我司出的一款数据库开发与管理工具——SQL Studio，100%自主研发，boss首要要求：写高质量代码。