所謂“山”**一開始不一定是“山”，只要你是程式設計師，基本都很難避免寫成“山”**在變成“山”之前可能很優雅**，其實是有乙個過程成為“山”**的。 尤其是那些接觸過“山”**的程式設計師，如果感到憤慨，你有沒有想過，自己可能是下乙個“山”**的創造者？ 當你忍不住想跑的時候，想想你第一次接觸“山”**時的心態，或許你會對“山”**有一定的了解！
我曾經在一家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主管的要求，但是在接下來的時間裡，每個車間的主管都向我提出了新的要求，最後在主介面上出現了大量的硬**。
不是這個東西不能重構，而是一旦重構了，軟體客戶就已經在用了，如果重構出了問題，這個責任誰也承擔不起，那就動手吧！
有趣的是，我們公司乙個年輕的程式設計師接手我的**時，因為不知道這個**是我開發的，直接告訴我這是“山”！
所以，《山》**和很多東西一樣，一開始可能很周到、很優雅**，但隨著時間的流逝，只能因為特殊的判斷、辛苦**或者因為害怕問題**而重構，只能重構，最後可讀性和可維護性慢慢變差，就變成了《山》。
不管是大公司還是小公司，其實都避不開“山”**我們有時會看到一些知名軟體突然有了大的更新，甚至前後感覺好像有兩個版本，老程式設計師一眼就能看穿發生了什麼！