“屎山”代码不一定一开始就是“屎山”，可能后面总有一个故事！

所谓的“屎山”代码一开始不一定就是“屎山”，只要是一个程序员，基本上都很难避免写出“屎山”代码！它成为“屎山”代码前或许还很优雅，变为“屎山”代码其实有个过程。尤其是那些接触到“屎山”代码的程序员，如果觉得愤愤不平，有没有想过，有可能您就是下一个“屎山”代码的缔造者？当您忍不住想跑路的时候，想想您刚刚接触“屎山”代码时的心态，或许您对“屎山”代码就会抱有一定的理解了！

一个软件开发的例子

我曾经在一家ERP软件公司上班，当时这家ERP软件公司产品已经迭代到2.0版本了，据研发总监说，之所以要迭代到2.0版本，那是因为1.0版本的框架实在是太“屎”了！

这家公司的老板曾经是国内一家很有名的ERP软件公司的研发经理，后来跟几个小伙伴出来单干创立的这个公司。老板和这几个小伙伴的能力都不错，对于1.0版本的ERP软件开发非常上心，很快就开发完毕。

因为当时国内的ERP软件公司比较少，他们开发的ERP软件一经推出就获得了客户的认可。ERP软件基本上都是按月、年付费的，但仅仅靠着月费或者年费肯定不足以支撑一家公司的生存。于是，老板故意采取低价月费和年费的方式增加自己产品的竞争力，而主要的盈利方式还是靠个性化需求的开发！当然，靠个性化需求开发盈利的这个决定也不是一开始就拍板的，所以，也为后面的“屎山”埋下了伏笔。

其实，一开始在写1.0版本的软件的时候，几个研发人员对于软件设计方面的考虑还是很周到的，毕竟是大厂出来的。但是，当用户量上来以后，还是会出现很多不在他们考虑范围内的需求。为了满足这部分人的需求怎么办呢？只能在底层代码上写硬代码或者增加插槽！但是，这和插件式开发不一样，插件式开发的前提是在框架基础之上预留接口，而他们遇到的，基本上都是需要直接修改源码的问题。

所以，在公司经营了几年后，原本的代码框架“千疮百孔”，根本没法看！于是，老板就准备重构1.0版本，开发2.0版本软件的念头，并且赋予2.0版本足够的后期开发灵活度。可是，尽管考虑得已经很周到了，但是2.0版本的软件还是遇到了和1.0版本的软件同样的问题！根本避免不了！

这只是一个小例子，那么，“屎山”代码到底是怎么来的呢？上面所举的例子有点太大了，下面举几个小例子。

“屎山”代码是如何产生的

比如，在某段代码里面有一个if语句，在程序编写之初，这个if语句假设需要判断一个数字是否为0，可能很多人就直接写if(num == 0)就完事了。但是，如果突然有一天，这个数字不光会变成0，而且会变成1、2、3……，在变成1的时候，可能大多数程序员依然只会增加一个else if(num == 1)，甚至是变成2、3的时候也会这样。

此时，这个if语句已经足够合适将它重构为switch-case了，但是，大多数程序员在此时其实都不敢动这段代码的结构，因为很可能会动出问题。

为了让这段代码继续保持不出错的状态，很多程序员此时可能明知道写更多的else-if只会将这段代码往“屎山”上推，但是，又不得不这么写！大多数情况下，“屎山”代码其实就是这么来的！

又比如我在负责一个项目的时候，因为客户那边是工厂，每个车间软件的主操作界面都是一样的，而子操作界面各有不同。于是，我在设计软件的时候，将主操作界面的代码基本上就定死了，而子操作界面可以根据不同的情况进行灵活配置。

我把软件设计发出来以后，相关人员纷纷夸我“考虑周到”、“简直完美”，结果实际情况是怎么样的呢？

某一天，车间A的主管说要在主界面增加一个功能，我跟他说加是可以加的，但是我得问问其他车间的主管是不是也要这个东西，结果其他车间的主管说他们不要，这就让我为难了。

后来，跟客户那边的研发人员一讨论，给出的解决方案就是根据车间类型在主界面增加特殊判断，用于功能按钮的显示和隐藏。我虽然很不情愿，但是上有老板，这个钱他得赚，下有客户，这个功能他要有，我只是个普通研发而已，只能硬着头皮写硬代码！

但是，这个事情没完，车间A的主管的要求我是满足了，但是接下来的时间里，每个车间的主管都向我提出了新的要求，最终主界面的代码里面就产生了大量的硬代码。

这个东西不是不能重构，而是一旦重构，软件客户已经在用了，重构出现问题，这个责任谁也担不起，于是，就这么着吧！

搞笑的是，我们公司一个年轻程序员在接手我的代码的时候，因为不知道这个代码是我开发的，直接跟我说这就是“屎山”！

结语

所以，“屎山”代码跟很多事情一样，开始它或许是考虑周到且优雅的代码，但是，随着时间推移，里面特殊判断、硬代码或者因为怕出问题只能累加代码而不能重构，最后慢慢得代码的可读性和可维护性变差，这才成为了“屎山”。

不管是大公司还是小公司，其实都避免不了“屎山”代码，我们有时候看到有一些知名软件突然就有大更新了，甚至前后感觉是两个版本，老程序员能够一眼看穿这其中发生了什么事情！