所谓“山”**一开始不一定是“山”，只要你是程序员，基本都很难避免写成“山”**在变成“山”之前可能很优雅**，其实是有一个过程成为“山”**的。 尤其是那些接触过“山”**的程序员，如果感到愤慨，你有没有想过，自己可能是下一个“山”**的创造者？ 当你忍不住想跑的时候，想想你第一次接触“山”**时的心态，或许你会对“山”**有一定的了解！
我曾经在一家ERP软件公司工作，该公司已经迭代到2根据研发总监的说法，版本 0 是需要迭代到 2 的原因版本 0，那是因为 1框架的版本 0 太“”了！
这家公司的老板曾经是国内一家知名ERP软件公司的研发经理，后来和几个朋友出去独自创办了这家公司。 老板和这几个朋友的能力不错，对于10版ERP软件开发非常用心，开发完成得非常快。
因为当时国内ERP软件公司相对较少，他们开发的ERP软件一推出就得到了客户的认可。 ERP软件基本上是按月或按年支付的，但仅靠月费或年费肯定不足以支持公司的生存。 因此，老板故意采用低月费和低年费来增加产品竞争力，而盈利的主要方式就是依靠个性化需求的发展！ 当然，基于个性化需求发展利润的决定并不是一开始就做出的，所以也为后面的“山”埋下了伏笔。
实际上，一开始我正在写 1使用0版本的软件时，几位研发人员对软件设计还是很有想法的，毕竟是出自大厂。 但是，当用户数量增加时，仍然会有很多需求不在他们的考虑范围内。 可以做些什么来满足这群人的需求？ 只能写底部**或加槽！ 但是，这与插件开发不同，插件开发是以在框架的基础上预留接口为前提的，他们遇到的基本上是直接修改源码的问题。
因此，在公司经营几年后，原来的**框架“漏洞百出”，根本看不出来！ 所以，老板准备重构 1版本 0，开发 20 个版本的软件创意，并给出 2 个版本版本 0 足以实现开发后的灵活性。 然而，尽管经过深思熟虑，2软件的版本 0 仍然满足和 1软件版本 0 也有同样的问题！ 这是无法避免的！
这只是一个小例子，那么，“山”**是怎么来的呢？ 上面给出的例子有点太大了，所以让我们举几个小例子。
例如，如果某个段落中有一个 if 语句，在程序的开头，这个 if 语句假设有必要确定一个数字是否为 0，很多人可能只是写 if（num == 0） 就完成了。 但是，如果突然有一天，这个数字不仅会变成0，还会变成......可能大多数程序员只会在它变成 1 时，甚至在它变成 1 时添加 else if（num == 1）。
在这一点上，这个 if 语句足以将其重构为一个 switch-case，但大多数程序员此时不敢移动这个 ** 结构，因为它很可能会引起问题。
为了让这个**保持无差错状态，很多程序员可能知道多写else-if只会把这个**推上“山”，但是他们不得不这样写！ 在大多数情况下，“山”就是这样产生的！
例如，我负责一个项目，因为客户是工厂，所以每个车间软件的主操作界面是一样的，子操作界面是不同的。 因此，我在设计软件时，主操作界面基本固定，子操作界面可以根据不同情况灵活配置。
在我发出软件设计后，相关人员称赞我“周到”“完美”，但实际情况如何？
有一天，车间A的主管说他想在主界面上加一个功能，我告诉他可以加这个，但是要问其他车间的主管要不要这个东西，其他车间的主管说不想要， 这让我很尴尬。
后来，在与客户方的研发人员讨论后，给出的解决方案是根据车间类型对主界面进行特殊判断，用于功能按钮的显示和隐藏。 虽然很不情愿，但是有老板，他要挣这个钱，有客户，他要有这个功能，我只是一个普通的研发，我只能努力写**！
不过，这件事情还没结束，我满足了车间A主管的要求，但是在接下来的时间里，每个车间的主管都向我提出了新的要求，最后在主界面上出现了大量的硬**。
不是这个东西不能重构，而是一旦重构了，软件客户就已经在用了，如果重构出了问题，这个责任谁也承担不起，那就动手吧！
有趣的是，我们公司一个年轻的程序员接手我的**时，因为不知道这个**是我开发的，直接告诉我这是“山”！
所以，《山》**和很多东西一样，一开始可能很周到、很优雅**，但随着时间的流逝，只能因为特殊的判断、辛苦**或者因为害怕问题**而重构，只能重构，最后可读性和可维护性慢慢变差，就变成了《山》。
不管是大公司还是小公司，其实都避不开“山”**我们有时会看到一些知名软件突然有了大的更新，甚至前后感觉好像有两个版本，老程序员一眼就能看穿发生了什么！