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

​

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

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

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

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

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

这是一种重构技巧，我之前写过一篇关于重构的文章：代码重构前vs重构后 也提到过通过这种手段，减少项目出bug的可能性。

那么其实这种手段也有副作用，就是代码越来越多，下一个同学如果也还是不敢改别人的代码，就会逐步堆积而形成屎山代码了。

那大家知道这种屎山代码是如何形成的吗？

我个人总结，一般是如下2个成因：

项目开发时间紧，任务重

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

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

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

再说另一个形成屎山代码的成因—离职率高。

如果一个项目相关的Owner一天到晚的变动，下一个人因为完全不理解前人写的某段代码意图，导致不敢改那段代码，于是他开始新增一段代码，供他自己所用，然后下一个接盘的小伙伴也按照这种思路，屎山代码终成。