阿粉最近在刷知乎的时候发现了一个很有意思的问题，那就是：为什么程序员会有代码能跑就不要动的观点？
说实话这句话在阿粉的工作中经常会听到，不仅仅是对于一些长期没人维护的代码，对于日常维护的系统哪怕是之前实现的代码，大家更是敬而远之，能不动一行代码绝不加个空格，更有甚者哪怕是复制一下之前的代码改改，也不考虑复用之前的代码，毕竟复制粘贴大法实在好用。
那么为什么程序员会有这种想法呢？
不得不说知乎的答主都说人才，同意一句：新人一优化，系统就会炸！
容易改出问题
首先当我们对系统不熟悉的时候，最容易改出问题，你是不是也遇到过明明就改了一行人畜无害的代码，结果服务就挂了，然而还找不到任何原因，最后只能回滚！这种情况往往是因为对系统的设计不了解的人，不知道哪里有坑，看着只是改了一行很简单的代码，结果导致了服务宕机。
经验告诉我们再修改任何代码的时候我们都需要搞清楚这段代码的真实意图和逻辑，不管是谁如果面对的是一段自己不熟悉的代码的时候千万不能随便动，因为很有可能会改出问题，动手之前一定要搞清楚代码的具体逻辑。
特别是新人！特别是新人！！特别是新人！！！
这里的新人指的是刚刚接触项目的人，跟工作年限关系不是特别大，新人虽然说因为没有经验偶尔会改出问题，但是并不代表有经验的人就不会改出问题，特别是有一些有多年工作经验的人，在面对新的环境和编程风格的时候，往往还是习惯自己的那一套，上来就大刀阔斧的改东西，结果导致各种问题发生。
这其实也是为什么有些公司愿意招聘一些毕业生，因为毕业生就好比一张白纸，可以慢慢培养，当然也可以理解成容易洗脑，哈哈哈。
成本问题
动不动代码取也决于我们对这段代码的投入是一次性的还是长久的，如果是一次性的那能不动就不动，因为不值得为了一次性的功能花费时间和精力去改动原有的东西，更不要随便就重构（虽然我知道很多程序员动不动就喜欢说重构）。
但是在工作中很多时候我们都会接手别人的项目，接手的项目肯定是后续我们需要维护和迭代的，这种项目未来会有很多需求和迭代，我们要动，而且要精雕细琢好好的动，弄清楚系统中的每个细节，在适当的时候该重写就重写，该重构就重构，因为我们的目的是让服务长久的运行下去，如果长期不动旧的代码，只往里面添加，那么系统只会变动臃肿，最后想维护都维护不起来。这个时候我们就需要通过一些设计思想和设计模式来改造我们的系统，使其变得更加活力。所以就要动了，也该动了。
真的改不动
其实阿粉觉得还有一种可能，那就是真的改不动啊~网上经常有段子，说一个程序员看到一段代码，不由自主的骂了一句：这代码写的就跟狗屎一样，然后看一下提交记录，打脸了，原来是自己几个星球前写的。说真的，这种情况经常会发生，很多代码只有在面临当时的业务需求的时候才知道为什么要这样写，时间一长根本记不起来当时为啥这么写，更不用说再重构了，要想重构也需要花费很多的时间去重新理解当时的业务逻辑，但是在业务推动的社会，老板哪有那个时间给你重构！
知乎网友的一个回答也很有意思，截图给大家看看。
是不是有一种蝴蝶效应的感觉，软件开发有的时候真的就跟蝴蝶效应一个样，不然也不会经常出现往往自己就改了很简单的一行代码，结果就崩了。
总结
总结一下该动旧代码的时候就要动。
技术是为了业务服务的，当我们的技术或者系统在不满足业务发展的时候就需要动，即使项目能正常运行，我们也需要进行适当的重构，作为一个合格的工程师，在设计系统的时候，我们要把眼光放到未来一年，提前做好设计和布局，这样就不会被业务追着跑，导致系统臃肿从而最后改不动！
所以小伙伴们你们在平时工作中有遇到过这种情况吗？欢迎在评论区留言说一说。
