为什么祖传代码被称为“屎山”？

嵌入式微处理器 · 公众号 · · 2024-04-12 15:55

正文

不知道程序员的你，曾经有没有维护过在 “屎山” 堆积而成的项目中，修改过相关功能的经历。

那种一个类动不动几千乃至上万行代码，一个方法也是几百几千行代码的神奇存在。

就在那里，你还不得不去理解里面的业务逻辑，还得去改部分代码。

有时候方法行参要么有超过5个类型参数或直接用一个Map类型来接受参数值，你都不知道上游会传具体哪些参数过来，完全抓瞎。

于是，稍有经验的程序员，秉持不影响原有功能的前提下，会重载一个新方法，仅仅改的那个方法，会调用新的重载的方法，其他之前调用链路，维持不变。

这是一种重构技巧，我之前写过一篇关于重构的文章《代码重构前 vs 代码重构后》，最后一个原则就提到过通过这种手段，进行高效重构，从而减少项目出bug的概率。

当然，那篇文章其他两个观点，也一样值得期待，比如结构化你的代码，高效单测等技巧，相信对你能写出一手漂亮的质量稳健的代码会有一定的帮助。

OK，那言归正传，我们再回到“屎山”代码这件事上来，相信会有小伙伴好奇：屎山代码具体是如何形成的？程序员为什么要写屎山代码？就不能一次性写好吗？

关于这些问题，我在之前的文章中都认真作了回答，感兴趣的小伙伴可以看一下：程序员为什么要一直改bug ？不能一次性写好吗？

最后，我认为程序员写出屎山代码无外乎以下两个成因：

一是，项目开发时间紧、任务重。

有些项目就是这样，总有那么多一堆理由，让你赶赶工，加加班，原本两周的活，让你一周完成。

这种情况下，能把代码写完都已经非常不错了，可以想象代码会被写成什么样，基本思路是，能怎么快，就怎么来，屎山代码初步形成。

二是，人员离职频率高，项目经历多代人维护。

再说另一个形成屎山代码的成因—人员优化或离职率高。

大家知道这两年，企业都在搞“降本增笑”，像最近的“飞书裁员”事件，就是这么一回事，企业觉得现阶段人太多了，业务呢又没跟上去，所以就要砍人，降低成本。

但砍人必定有一定的副作用，如果一个项目相关的Owner一天到晚的变动，代码经过一手又一手，每一个刚接手的小伙伴因为完全不理解前人写的某段代码意图，导致不敢改那段代码（担心改了会炸），于是他开始新增一段代码，供他自己所用，然后下一个接盘的小伙伴也按照这种思路，屎山代码终成。

PS：尽管有很多客观因素影响到我们程序员写出好的代码，但条件允许的情况下，我们还是要竭尽所能写出好的代码，对自己负责也对他人负责。

END

来源：陶朱公Boy

版权归原作者所有，如有侵权，请联系删除。