在程序员行业有一句:“代码和人，有一个能跑就行”。这句话对吗？为什么会产生这个问题？

哪些代码能跑就行？

有一些代码，真的就是不能动，一动就崩。里面逻辑复杂， 代码冗余，具备了一些不良代码的特征，但是它就是能跑，就是能支撑业务。有一个通俗的称谓为“屎山代码”。 

哪些是dirty code

• 缺乏注释和文档：完全没有注释或者复杂逻辑无文档
• 命名不规范：变量、函数和类的命名不符合约定或没有约定 例如a,b,c,变量用动词，方法用名词，驼峰下划线混用等
• 代码重复：同样的代码逻辑在多个地方重复出现，增加了维护的难度。 代码不做抽象，公共方法复制拷贝，一个方法复制多份
• 复杂的逻辑：代码逻辑过于复杂，缺乏清晰的结构和模块化设计。
• 硬编码值：使用硬编码的数值或字符串，而不是使用常量或配置文件

dirty code是如何产生的？

时间压力

项目不给足够时间，倒排期工程，项目经理整天催催催，老板天天问进度。预计5天，报了6天，砍到3天，1天的时候问做到哪了，2天问怎么还没做完。 你让我抽象，你让我搞架构，但是不给我时间，写出来的代码优先要进测试，提了bug再改改呗，反正缝缝补补又3年。

过于自信

自认自己的代码足够牛b。

不需要注释就可以看懂，不就是几个变量名吗？别人理一理逻辑就可以了，我的代码自己可以解释自己。 不需要抽象，这里都是一整套逻辑的。什么？你也要用这套代码，自己复制出去，别动我代码。我们要签订《代码互不侵犯条约》。

经验不足

新手小白能完成任务就不错了，什么鲁棒，什么设计模式，完全不需要考虑。一个函数500行？抱歉那是这个功能的瓶颈，不是我的瓶颈。

企业文化，标准/规范缺乏

你还记得你上一次做code review是啥时候吗？在夜深人静的时候，有没有回想每天996为啥老板还没开上大奔？

老板要的是结果，不是过程，代码写的再好，最后业务不核心，不干掉你干掉谁？

防御型编程

这个不多说了，懂的都懂。

明明知道有问题，为什么不重构呢？

重点项目，核心代码，不敢动。

在一些关键项目中，核心代码往往被视为系统的“心脏”。由于这些代码对于系统的稳定性至关重要，任何改动都可能带来巨大的风险。一旦出现问题，不仅影响系统的正常运行，还会直接影响团队的绩效和公司业务。因此，程序员往往选择维持现状，尽量避免对这些代码进行大的改动。

边缘项目，长期不迭代代码，不敢动。

对于一些边缘项目或已经很久没有进行过迭代的代码，由于缺乏持续的维护和更新，这些代码的整体质量和可读性往往较低。如果要对其进行修改，可能需要对整个系统进行全流程回归测试，这不仅费时费力，还可能导致人力资源的浪费。因此，除非遇到重大问题，否则这些代码通常也不会轻易被动。 

代码能跑就行的结果是啥？

经过你一系列深思熟虑，不断优化重构，代码终于写的跟诗一样的。但是你的工期比别人多了1/2，虽然bug少了，但是研发成本大增。

尽管你的代码十分优秀，但不出意外的，在绩效评定的时候，你只拿到了及格。相反，另外一个能跑就行的同事，在每次线上出现问题的时候，都能及时化解，拿到了优秀。

因为你的项目进度慢，一些新项目和重点项目优先分配给了其他人。

慢慢的你对这家公司失去了信心，转投其他公司，但新公司的领导看到你的代码，惊为天人，于是你顺利的走上人生巅峰（给个happy end吧）。 

究竟应该怎么做？

中国人讲究“中庸”,大多数情况，在非开源项目或公司无具体要求时，要求我们要掌握一个开发成本/代码质量的度。

尤其在一些并不太优秀的团队中，我们优秀的代码质量无法为我们换得足够匹配的价值回报。相反，交付效率/交付质量/线上稳定性才是优先考虑的问题。

尤其在现在降本增笑的大环境下，保护自己才是最重要的。

但优质的代码，带来的是身心的愉悦，后续维护的简单，代码的灵活性更高。建议在核心代码，工具类等优先使用高质量代码，而在一些增删改查，非核心/重点项目内容上，还是难得糊涂一下吧。