为什么程序员会有代码能跑就不要动的观点？
核心理念的本质：风险控制与稳定性优先
本质上，“代码能跑就不要动”是一种基于风险控制和稳定性优先的工程哲学。任何修改，无论初衷多么良好，都不可避免地引入了引入新错误的风险。软件系统往往是高度相互关联的，一个看似微小的改动，也可能在系统的其他地方产生意想不到的副作用。
详细阐述其背后的原因：
1. 意外副作用（Unforeseen Side Effects）：
相互依赖性： 现代软件系统通常非常庞大和复杂，由成千上万行代码组成，这些代码又由不同的模块、类、函数甚至服务相互调用和依赖。一个函数可能被系统的多个地方使用，修改它可能会影响到所有调用者，而你可能只注意到了其中的一部分。
隐藏的逻辑： 有些代码可能承载着一些不为人知的、历史遗留的或特定的业务逻辑，这些逻辑并没有被充分文档化，或者其重要性在当时的实现者离开后变得模糊。对这样的代码进行“优化”或“重构”，很可能破坏这些隐藏的关键。
全局状态与副作用： 如果代码修改了全局变量、共享内存或执行了具有副作用的操作（如修改数据库、发送网络请求），那么任何对其的改动都需要极其谨慎，因为这些副作用可能会在程序的其他地方产生难以追踪的后果。
2. 测试的局限性（Limitations of Testing）：
测试覆盖率并非100%： 尽管自动化测试是现代软件开发的关键，但几乎不可能做到100%的代码覆盖率，更不用说100%的逻辑覆盖率和100%的边界条件覆盖率。即使有详尽的单元测试、集成测试和端到端测试，也可能存在未被覆盖的路径或组合。
真实世界环境的复杂性： 测试环境永远无法完全模拟生产环境的复杂性，包括各种用户输入、网络延迟、并发访问、硬件差异、第三方服务行为等。即使在测试中表现良好，上线后也可能因为这些差异而出现问题。
“幸存者偏差”的测试： 如果一段代码在过去十年里一直运行良好，它可能已经通过了无数次的测试和实际运行。修改它，就等于冒着“打断”这种已被验证的稳定性的风险。
3. 维护成本与收益的权衡（CostBenefit Analysis of Maintenance）：
时间与精力投入： 修改代码需要时间去理解现有逻辑、编写新代码、进行测试、部署和监控。如果现有代码虽然不够优雅或高效，但能够稳定地完成其功能，那么投入大量时间去修改它，可能不如将这些时间用于开发新功能或解决更紧迫的问题来得有价值。
技术债务的积累与偿还： 软件开发中存在“技术债务”，即为了快速交付而牺牲代码质量、可读性或可维护性所产生的负面影响。偿还技术债务是必要的，但何时偿还、如何偿还，需要权衡。如果一段债务代码不影响业务，且风险极高，那么在没有充分准备和测试的情况下，就不是“非动不可”的情况。
投入产出比： “能跑就不要动”强调的是投入产出比。如果修改带来的好处（如性能提升10%、代码可读性增强）远小于修改带来的风险（如引入bug导致系统宕机）和成本，那么保守的做法就是不轻易改动。
4. 对现有稳定性的信任（Trust in Existing Stability）：
“Don't touch it if it works”： 这是一个非常直观的逻辑。如果一个系统在一段时间内稳定运行，并且满足了所有业务需求，那么它就已经证明了自己的价值。对其进行改动，就是增加了潜在的失败点。
历史经验的教训： 许多有经验的程序员都经历过由于一次“不必要”的代码修改而导致的生产事故。这些经历往往让他们对改动现有稳定代码持谨慎态度。
5. 重构的必要性与时机（Necessity and Timing of Refactoring）：
“重构”不是“随意修改”： “代码能跑就不要动”并不排斥重构。重构是为了改进代码的内部结构，而不改变其外部行为。这通常是在有明确的改进目标（如提高可读性、降低复杂度、提升性能）且有完善的测试保障下进行的。
时机不对会适得其反： 如果在赶项目进度、压力巨大或缺乏足够测试支持的情况下进行重构，反而更容易引入问题。
什么时候可以“动”？
当然，“能跑就不要动”并不是绝对的教条，而是需要根据具体情况判断。以下是一些“动”代码的合理理由：
bug修复： 代码中存在bug，影响了正常的功能实现或用户体验。
安全漏洞： 发现并需要修复安全漏洞。
性能瓶颈： 代码严重影响了系统性能，需要优化。
重大功能改动或新需求： 需要修改现有代码以支持新的业务逻辑。
技术债务累积过高： 现有代码的可维护性、可读性极差，严重阻碍了后续开发和维护，需要系统性地进行技术债务的偿还。
过时的技术栈或库： 需要升级以获得安全更新、性能提升或兼容新环境。
经过充分测试和风险评估的重构： 目标明确，且有信心通过测试保障修改的正确性。
总结：
“代码能跑就不要动”是一种强调谨慎、稳定和风险控制的工程哲学。它源于软件开发的复杂性、测试的局限性以及维护成本的考量。它提醒程序员在进行任何代码修改时，都要充分评估潜在的风险和收益，并优先考虑系统的稳定性和可靠性。这是一种在实践中不断被验证和强化的经验智慧，尤其是在维护大型、关键的生产系统时更为重要。
网友意见
这个观点害死了很多人。。
说一段我自己的经历吧：
2010年加入创业时期的360，担任高级工程师，负责一个远控软件，同时要跟操作系统底层打交道。
入职后才发现在Leader的神操作下，部门的代码耦合成了一个大泥球，一个主类就有几万行，主类里的一个函数就有几千行。。
那个Leader最常说的就是：能跑起来不要想着去改，跑起来就行！
后来因为副总裁要求一个大功能，这哥们直接卡壳了，他带着我们几个小弟想改改上线，发现怎么都改不出来，，硬是delay了1个月都做不出来。
副总裁直接怒了，快速给他转岗到其他部门，让我先暂代技术经理职位，同时开始招聘。。。
面对前任Leader留下来的数十万行耦合严重的代码和框架（大白话：代码屎山），压力巨大。360素来以打仗凶猛著称，发版以天计，那段时间一天好几个版本。面临的最大困境是：如何在高速迭代的过程中重构整个旧的框架。至今还记得，面对那个主类的心情，那是崩溃和无力的。但越大的压力，你扛下来往往是更高的成长速度。
一瞬间，又回到了大三的那种疯狂状态，每天极限Coding，甚至接近入定的状态，上班往那一坐基本不动弹，就靠几瓶水几个面包，一天的三餐就对付了。
我们将代码组件化、模块化，实现了一边飞奔一边换轮子。就带了两个实习生，花了3个月搞定了这一堆恐怖的代码。
当系统彻底被改造完毕之际，那种兴奋难以言表。
因为成功完成了技术改造，同时还满足了副总裁的各种需求，副总裁直接给我晋升技术经理，招技术经理也再没提过了。
那段时间为了更好的重构代码，我还看了很多计算机经典书籍，包括《重构》、《代码整洁之道》《高性能Web编程》等等，把书本上的知识应用于工程实践，这种成长真的是难以言表的舒爽。
顺便送大家一份非常宝贵的计算机经典书籍资料，我把工作中用的经典电子书库（包含代码重构、数据结构、操作系统、C++/C、网络经典、前端编程经典、Java相关、程序员认知、职场发展）、面试找工作的资料汇总都打包放在这了，学完进大厂很容易：
我已经帮大家打包好了，点击下方链接直接获取：
这段时间，我的架构思维开始突飞猛进，我们在每一次的重构之前，都会先画出业务时序图、类结构图、工程关系图，然后按图索骥，每每在实现的那一刻，不由得惊叹：程序世界，太奇妙了。
所以你看看，带着代码能跑就不要动的观点，真的会害死人的，程序员有的时候就得直面大泥球，不断重构，不光锻炼能力还能保证后续需求的迭代。
干这一行的老兵都知道，稍微上一点规模的代码库，都是很复杂的，多年积累下来的各种奇奇怪怪的需求，导致了各种代码补丁和Hack，这些复杂度是外行难以真正体会的，在这种复杂度下，看起来人畜无害的一个修改，很可能导致连锁反应，然后代码屎山会爆炸的！
但不全是坏消息，好消息是——软件这玩意没有磨损！
换句话说，只要软件现在能运行，在外界环境不干扰的情况下，软件会持续运行下去！
就拿网上这张著名的图来说，大家很可能觉得这真是凑合，因为这个红绿灯已经坏了，不去修的话，风吹雨打，最后红绿灯肯定会彻底坏掉的。
但是，在软件的世界里，和硬件不一样，软件是没有磨损的，管他风吹雨打，软件还是一样的0-1序列，硬件坏了，换一个同样规格的硬件就是了，软件继续运行。
所以，真的，只要代码能跑的起来，能不动就不要动了，此乃经验之谈！
在实现鸽子飞行功能的过程中，程序员使用传统技能ctrl+c复制了百度/谷歌搜索到的CSDN上直升机类中旋转螺旋桨的飞行方法，并抱着实践出真知，跑起来就不算错的心态，直接粘贴到项目中鸽子类飞行功能中，并将符合方法参数类型的鸽子头绑定到了一起，代码顺利运行！
发现效率和控制方法上有些许差异，于是减小了头的旋转周期并给脖子添加了控制飞行方向的方法，随后更新了代码文档。
数日后，负责鸽子程序的程序员鸽子了程序，新来的程序员吐槽了老员工后，将飞行代码的参数由鸽子头修正为鸽子翅膀：
有一个原因其他回答没有提到：
因为在国内互联网大厂，主要产品的程序靠谱与否、流畅与否，消费者都只能买账，特别是那些动辄上百MB的巨型聊天、购物软件。流畅也得用，不流畅也得用，崩溃了你都得硬着头皮重启用。
每个应用都越来越卡，卡到你受不了，只能换新手机。国外程序员代码是写的好，可你我总不能在国内用eBay日常购物上Uber叫车上电报日常汇报工作吧？
既然跟计划经济时代的自行车一样不愁你不买涨，程序员还优化干啥？自然有各种困难理由。
就说健康码吧，最新款的iPhone13ProMax，开支付宝+开健康码竟然也要二三十秒，前两年的旗舰更是快1分钟，查询流量大的时候还白屏。
嘿，人家就是不优化，人还觉得30秒能查出健康码老厉害了，你有本事把防疫人员物理说服了，不然就乖乖憋着。
假如苏联的某个汽车厂厂长说：汽车能开的动，就不用更新换代，那的确计划经济，大家只能买他们的车，但这种言论会被做成苏联笑话在中文互联网上传承；
到简中IT行业，这就成了屎山动不得了。
这就和为啥钢铁厂和电站有一本厚厚的安全手册一样。。那本安全手册中的每一句都是人命累积而成的。
你以为这些代码写在哪里，看起来很蠢。。但是他们都是为了满足某一个时间上的一个需求写出来的。只不过，电脑程序有特殊性，你改了代码，大不了程序跑不起来。没啥大危险性。
你要这么喜欢系统重构，建议你下次去钢铁厂和电站进行这种工作。你去看看知乎上生产事故中的那些二货，有看汽轮机皮带斜了，用脚矫正，直接截肢的。有看炼钢炉出水口歪了，手欠去拨动，直接化灰的。
首先，这句话显然不是程序员专属的，而是一句著名美国俗语的意译。
if it ain't broke, don't fix it
不要跟我争论语法。
也不要跟我争论说明明你是在某本技术书上看到这种说法的，毕竟这句话在 1970 年代就流行了，被后来的技术书籍反复引用难道不是很正常么……
反过来，正是因为技术书和技术讨论中会引这句话，所以你看到的时候它已经被意译得不那么接近原貌了。
然后，这句话本身流行开来的背景也很简单，就是一个政府官员 (Bert Lance) 表达了反对某些类型的改革的立场：
Bert Lance believes he can save Uncle Sam billions if he can get the government to adopt a simple motto: "If it ain't broke, don't fix it." He explains: "That's the trouble with government: Fixing things that aren't broken and not fixing things that are broken."
但是各位习惯键政的可能立刻就看出来问题了。
Lance 也不是真的字面意义上的反对一切改革。他纯粹是反对那些他反对的改革，支持那些他支持的改革——就像那些他这样的政客一样。（废话体在这里还真好用）
这个政治版本的俗语，其实关键点根本不是这个近乎语意重复的因果关系，而是“什么是 broke，谁来规定哪些东西 broke 了”。 Bert Lance 可能觉得政策 A 是 broken 的，得改，而觉得政策 B 是不 broken 的，不应该改。换一个人说同样一句话，可能他其实想表达的意思是完全相反的。
翻译到这里，你就会发现这就是最最最平常的政治辩论，“我说得对，你说得不对”。仅此而已。
既然说完了这句话本身的来源，那么我们再看软件。那么上面的政治版问题直接翻译过来，就是这些：
什么叫“代码能跑”呢？
谁来定义“代码能跑”呢？
一份代码是否“能跑”，取决于哪些条件？这些条件何时会变化？
这几个问题其实并没有通用的回答，而我觉得回答这几个问题，比纠结这句话本身在说什么要有意义。
而这句话本身，大概就是一种把自己的观点包装在废话体后面的话术吧。
你是刚入职的程序员, 发现公司的代码一团糟. 你在想"这是谁写的烂代码". 你决定尝试优化清理下.
优化需要产品测试运维的配合. 他们推脱没有收益? 你成功的用"追求卓越"勾起了他们曾经的激情
经过一个月的努力, 优化版本上线了.
这里有两种结果:
- 代码运行非常稳定. 你得到了精神上的满足. 但是领导完全没感知. 没人会得到奖励
- 代码出现bug并影响了用户. 领导感知到了. 你以及被你鼓动起来的人都被处罚.
让我们总结下. 最好的结果是你们辛苦一个月没有物质收益. 更可能的结果是你们辛苦一个月最终被处罚. 现在你大概开始认识到这是多么愚蠢的投入了吧.
什么? 你还是认为这种尝试是有价值的? 小伙子你精神可嘉, 如果幸运遇到个好的平台一定是个不错的程序员. 但是好的平台太少了. 我这里说的好的平台是指:
- 管理层是内行人. 能意识到优化的收益
- 管理层明白这种优化的根基, 优化带来的风险自己抗而不是让手下抗
- 管理层扛得住. 公司扛得住
- 公司有能力从这种优化中得到收益. 而不是浅尝辄止
想想就明白, 这种平台万中无一
类似的话题
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有