要运行1+2+3+4，有A, B两个代码。

A代码：1+2=2

B代码：3+4=8

运行1+2+3+4=A+B=2+8=10，结果正确，皆大欢喜。

有一天一个程序员看到了代码A，发现了问题，修改A：1+2=3

那么再次运行1+2+3+4=A+B=3+8=11，结果错误，而错误的B代码藏得很深，根本找不到。

修改了某一个代码可能会像蝴蝶效应一样影响其他代码，导致大厦倾倒。

浅显理解，欢迎指正。

“代码能跑就不要动”其实底层无非以下几种情况

一：隐藏有雷，怕暴雷。

1：首先作为产研的同事要有一个基本意识：是个bug迟到会暴露，是个雷迟早会炸。

对于公司的风险，暴雷的风险始终存在；

但对于开发个人而言，这种暴雷的风险不一定有，只要这个雷在他履职期内不爆发，所以这就是一般的人不愿意触碰别人的东西，因为一不小心就会踩雷。一是本身就是个雷，可能一直没触发到，自己一碰就炸惹一身骚扯不清楚，而且自己不一定有驾驭能力能排掉这个雷，搞不好整个连环雷噼里啪啦炸一片；二是以前都是好的，自己要继续迭代，由于自己了解的不全面，思考不全面，加上专业度测试问题，最后可能带来新的雷。但是这两种雷都会被结算到这个身上，很憋屈。

其实要不要动这个问题，核心还是自我定位，自我要求的问题，如果你觉得自己就是个过客，就是个打酱油的，那没办法，跟这种人说再多就没用，必然就是“能跑就不要动”的心思，你如何对公司，公司必然如何对你，这种人能用就用，不能用就让走人，因为个人价值观这种东西不是靠洗几次脑，三五个月能改变的。

如果自我要求高，对自己个人品牌负责，对公司负责，那肯定遇到雷，就想法设法去拍，尽管过程可能会带来连环雷啥的，但坚持努力下去，一定会带来个清明世界，这也是自我价值的实现，也是公司重点培养的有责任感有担当的人才。当然发现有雷，不是立马硬着头皮去搞，首先一定要做到足够了解，从关联的产品需求的了解，到关联代码的通读，该问产品问产品，该问开发问开发，做到了然于胸再开始干。大部分改别人的bug出现的按下葫芦起来瓢的问题，都是了解不透导致的。然后测试场景一定要全，一起梳理代码关联的上下游测试场景。

二：对现有的技术框架/代码风格不认同，但重构工作量大，有风险，又怕hold不住

比如老项目的框架可能已经过时的，自己又不想降维用老框架去写东西，毕竟从技术含量或者技术提升来说，投入产出比较低。任何公司都会有这种情况，因为基于稳定性的要求，基于各种综合因素的原因，必然会有框架技术较老的项目。这时就需要站在公司的角度去考虑问题，可能从当下的角度，不升级框架就是最好的选择，就选择不动；从公司发展的角度或者当下可以做升级的规划的时候，就需要提出整改，重构的技术方案，去推动项目的重构。重构是一个特别苦逼，但特别有挑战力的事情，而且成就感超大。因为事情一旦干成，看到全新的框架体系，看到更专业的代码设计与实现，那种成就感真的会爆表。

综上，其实我是不认同 “代码能跑就不要动” 这种价值观的。做技术的还是要有点追求，而不是一味在企业追求“安全感”，寻找“舒适区”。虽然有时候可能会按下葫芦起来瓢，可能会连环雷，可能会被质疑，但这都是成长蜕变的必经之路。做技术的核心竞争力还是专业度，以及基于专业度之上建立起来的信任感，但实现过程中离不开对技术对自己的高要求 和 对事对企业的责任心。

假设我们有一个需求，让老李向平安县城发射意大利炮。（目的明确，方向清晰）

突然，出了异常！小鬼子绑着秀芹出现在了平安县城上！（出现异常，需求变更）

接下来，小鬼子谈判，要老李投降。老李问候了小鬼子八辈祖宗，小鬼子打了一梭子子弹，干掉了老李的炮兵，老李有点傻眼了，现在只有魏和尚会打这个炮。只能赶紧派人把魏和尚叫过来  (原有的能够实现需求的代码不能用了，只能引入第三方)

魏和尚来了之后，看了看，团长，这个炮射程有点不够，咱们需要把它往前挪一点。老李马上安排三营长调了一个班的战士来掩护（引入第三方依然不能满足需求，需要公司调配更多的资源来支撑）

此时秀芹在城楼高喊“老李，开炮啊，不开炮不是男人”（需求的实现有点延期了，项目经理的权威得到了巨大的挑战。）

终于开炮了，虽然命中了一些目标，但是并没有一击致命。（功能实现了，但老板并不满意）

最让老李头痛的是，炮弹打完了，政委迟迟没有回电（开发资源不够了，老板也没有调经费的打算。）

剩下的炮弹因为下雨进水，成了哑炮。（原有的技术模块过期了，用不上。）

老李打了个电话给楚云飞，借了炮弹过来，但是欠了楚云飞的人情（欠下了技术债，以后老李跟楚云飞喝酒要把杯子压低点）

平安县城终于被拿下了（需求得到完美的实现。但是老李也付出了伤亡惨重的代价）

老李OS： 俺老李能打下平安县城已经是豁出半条命了，你还嫌我进攻的姿势不够优雅，要再来一遍？

成本，效率，风险，收益的综合考量吧~~

能跑证明能满足基本的需求

再去改，就会产生满足需求之外的时间和劳动力成本

在需求实现完成效率角度来看，改的次数越多，效率越低

改动伴随着风险，改完之后能不能正常运行也许是个问题，改动意味着提高了风险出现的概率

整体收益来看，成本增高，效率降低，风险增大，收益是降低的。所以能跑就别动客观上来讲是合理的。

【心】：作为i一个资深代码人来回答这个问题。

【田】：当我们写代码时，需要有一个既定的代码规范，术语叫lint，是一个静态的代码分析工具。分析的事项有》引用、大小写、空格、符号、单复引号、换行、括号的使用。除此之外还有代码的检查，代码的覆盖率检测，codereview，等等一系列手段保证代码的运行通顺的同时，可以让别人理解代码。

但是还是会发生以上情况，是为什么呢？

第一是人的问题，大多数写出以上代码的人，对于代码的理解和布局理解不佳，一般以CV为主，仅仅是抄袭一个过程，就导致了各种书写的代码方式不同，逻辑不同，但是功能类似，因此修修补补就运行起来了，你要是去做调整，就无从下手。

第二个就是繁复的业务，当一个浓重的业务放在面前的时候，为了时效性，大部分选择的也是最快的方法，写出来一些共通抽象，然后——复制粘贴。对于代码的设计规范是充耳不闻，什么抽象，继承，复用都是可以没有的。

第三就是编程语言本身很复杂，比如c/c++，需要自己定义很多内存指针，不同人的不同思想指导下，就没有办法修改，需要查找上下文关系，改动起来极难。

第四是面向解决问题的语言，像大部分算法工程师和算法的学生以及教师们，大多数是拿代码来解决问题，那么就不会去考虑代码的排版布局，仅仅是为了解决问题而解决，所以对他们来说，领域内的内容是可以看懂的，跨领域的人是无法修改的。

敲代码跟盖大楼一样，打地基，搭框架，分房间，赋予每个房间功能（厨房是做饭的，客房是休息的）当你盖了10层，发现想改第4层，不是直接就可以改，上面还有6层呢。

1. 风险大，动1cm上面塌了

2. 代价大，你得稳定整体大楼，付出的代价会大于挪动4层的代价

3. 不确定性，更改了4层，上面基于4层搭建的确定可以使用嘛
   

只要我挖的坑够多够快，以前的坑就追不上我，没有什么BUG不能用更大的BUG来盖住

反过来说，调整1个问题，有可能引申很多历史的坑。。

这个问题我不改，顶多难受，但是我可以忽悠过去就行

这个问题改了，万一改不好，可能我工作就丢了，换我也不改

我觉得是不能轻举妄动，的确，看到很多代码都是经历好多人的合作而成的，即人员替换，所以有些代码看似不合理是会有的，而且交替迭代，改一个可能影响很多，牵一发而动全身啊。

什么情况下可以改呢？明显看出影响范围和新代码保证质量的情况下。

无非就是整体代码水平有限，担心按下葫芦起来瓢这样的事情。这样的情况，我都见怪不怪了，比较大部门程序员只是码农，雷布斯这样的大神少之又少，加上99.99%的软件公司软件开发管理能力等级CMMI 只停留在初试级！

在你眼里就是简单的改一个按钮

可能之前为了实现这个按钮功能

不知道后面到底有多少逻辑才能实现这个按钮的

改了这一个按钮，研发可能需要review所有代码

然后改整个框架等等，除非有需求要优化重构了

要不然都是缝缝补补又三年，用到离职那一天

每日一答，向ella更近一点点:

问题：代码能跑就不要动

瞎说：“编程的第一法则：如果您的代码以某种莫名方式跑起来了，就不要再碰它了。”

这是技术大佬跟我说过的一句话，感觉很戏剧，又很喜剧。

也有人说过，代码优化是一把双刃剑，想去优化代码是一件好事，但并不能保证每次优化都会是好结果。如果这一次优化刚好是特殊情况，很有可能增加不必要成本，甚至可能会让软件优化了还不如没优化。

代码好改，结构难变！

开发人员的第一法则：如果您的代码已经跑起来了，请不要尝试修改它了！

不经过系统分析调查代码，轻易地去修改或者优化代码，结果就是：地雷、暴雷，连环雷，未知雷，甚至系统直接多米若骨牌效应的不断暴雷未知的雷。

没事儿别乱动，跑个一年半载的不是问题，如果产品经理总认为代码好改，那为什么他们不转做技术做开发呢？当然不要去杠精，开发人员有站在产品的角度，开发前期就酌情参与到了解用户过程中，就能减少团队磨合的时间成本了。

牵一发而动全身。

改动一个地方，就需要牵扯出来很多的地方都要修改，就像咱们产品画原型一样 ，一个地方改动了字段，那你这个业务逻辑线上的原型当中的字段你也得改一遍，你不改，开完以为没有这个字段，然后他也不管，上线就出问题了。

所以，这就是很多软件越更新越大，以至于臃肿之后优化成本更高的原因之一吗？另一个原因是手机/笔记本需要换代？