什么是『屎山代码』？

我自己总结的定义是：

编码层面：

代码编写严重不符合编码规范；代码混乱/重复/冗余，难以维护；变量命名/类命名/方法命名/包命名/数据库字段命名混乱且没有规范；代码中充斥着常量和硬编码；代码中充斥着大量if…else…；一个方法几百行甚至上千行是常态。

架构及设计层面：

项目基本没有架构设计；技术选型没有经过严谨的讨论和考量；不同模块之间的功能划分/边界确定/互相调用一团混乱；每次功能开发前没有出详细的技术方案亦没有评审；最终导致项目结构混乱，包组织混乱，方法调用混乱，不同模块之前方法调用混乱，整个项目乱的像一团麻，难以维护和快速迭代。

屎山代码和祖传代码的异同？

『屎山代码』跟『祖传代码』还不同，『祖传代码』指陈年累月、伴随公司业务发展/变更/开发人员变更而产生的，有的『祖传代码』在刚开始开发的时候，是有严格的编码规范和良好的架构设计的，但经年累月的随着公司业务发展/开发人员变更才慢慢变成所谓的『屎山代码』。

所以『祖传代码』可能是『屎山代码』，但『屎山代码』不一定是『祖传代码』。我见到很多最近两三年才立项进行开发的项目，项目从一开始就缺乏架构设计和编码规范，可以说这些项目从一开始，就是一小坨『屎山』。

在中国当程序员，不管是进大厂，还是小创业公司，总是会相当概率遇到『屎山代码』。那么我们追根溯源问一句：『屎山代码』到底是怎么产生的呢？

一个常见的、大多人公认的原因，是“程序员水平低”。呃，又是程序员背锅。

其实造成『屎山代码』的原因很多，不可否认“程序员水平低”是造成屎山代码的原因之一，却并不是根本的原因、也不是唯一的原因。

过去十几年，中国互联网行业野蛮发展，风口一个接一个，很多老板都要求新产品必须在指定的时间点开发完成上线，而这个压力，往往最终压在了程序员身上，通常是，产品原型还没有，产品经理还没想清楚产品设计，就要求程序员开始进行开发了。开发任务重、上线时间紧迫，需求还总是在变化，最终压力传导到这条链条的末端 – 程序员身上，那么代码质量就可想而知了。

屎山越堆越大越堆越高，最终当这批程序员也感觉开发起来费劲、维护起来难受时就该跑路了，留下的屎山由下一任程序员接管。

软件开发中有一个不可能三角定理，大致意思是说：开发速度、代码质量、项目后期可维护性，三者之间很难兼得。

很多创业公司刚起步的时候，做项目往往没有什么架构设计/开发规范/技术选型，怎么快怎么来，先把项目搞起来再说，往往顾不上、或也不懂什么架构设计/开发规范/模块拆分（其实这个时候如果有合格的架构师去设计良好的架构和规范是会提高开发效率的），随着后期业务量越来越大，原先的项目再想重构就很难了，地基没打好，架构有问题，项目很难维护和扩展，为了减少出问题的概率，往往选择一点点往旧项目上堆代码，久而久之，就出现了所谓的『屎山代码』。

简单总结就是：在软件开发的整条链路上，任何一个节点的人的不专业、不遵守软件开发的客观规律，都会导致了屎山代码的产生。

完。