不知道程序员的你，曾经有没有维护过在“屎山”堆积而成的项目中，修改过相关功能的经历。那种一个类动不动几千乃至上万行代码，一个方法也是几百几千行代码的神奇存在。就在那里，你还不得不去理解里面的业务逻辑，还得去改部分代码。

有时候方法行参要么有超过5个类型参数或直接用一个Map类型来接受参数值，你都不知道上游会传具体哪些参数过来，完全抓瞎。于是，稍有经验的程序员，秉持不影响原有功能的前提下，会重载一个新方法，仅仅改的那个入口方法，会调用新的方法，其他之前调用关系，维持不变。这是一种重构技巧，我之前写过一篇关于重构的文章：代码重构前vs重构后 也提到过通过这种手段，减少项目出bug的可能性。

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

我个人总结，一般是如下2个成因：
1.项目开发时间紧，任务重
有些项目就是这样，总有那么多一堆理由，让你赶赶工，加加班，原本两周的活，让你一周完成。这种情况下，能把代码写完都已经非常不错了，可以想象代码会被写成什么样，基本思路是，能怎么快，就怎么来，屎山代码初步形成。

2.人员离职频率高，项目经历多代人维护
再说另一个形成屎山代码的成因—离职率高。

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

那么有哪些方式可以尽量避免屎山代码的出现呢？这里总结一下：

设计良好的代码架构：在编写代码之前，应该花时间设计一个良好的代码架构，以确保代码易于维护和扩展。
遵循编码规范：在编写代码时，应该遵循编码规范，以确保代码风格一致，易于阅读和理解。
模块化开发：将代码分解为较小的模块，可以更容易地进行测试、修改和重构。
代码重构：在代码出现重大问题之前，应该及早进行代码重构，以避免代码量过大、复杂度过高。
持续优化：在编写代码的过程中，应该持续进行代码优化，以提高代码的性能和可读性。
代码审查：进行代码审查可以发现潜在的问题，并提供改进建议，以避免屎山代码的出现。
维护代码文档：维护清晰的代码文档可以帮助其他开发人员了解代码的结构和功能，避免不必要的错误和冲突。

给开发人员预留足够的开发时间：每一件精致艺术品的出现都是用时间精雕细琢的结果，我们开发程序虽不比艺术品雕刻，但是也要给开发人员留够充足的开发时间，这样开发人员才会有更多时间去思考如何更好的实现代码功能。毕竟，大部分程序员还是很珍惜自己开发的产品的，谁都不希望自己写出来的代码被人说成屎一样的代码。

总之，避免屎山代码的出现需要开发人员的努力和持续优化，需要遵循良好的编程实践，并注重代码的可读性和可维护性，当然这些都离不开时间的滋润。