本文轉自公眾號：美男子玩程式設計
“屎山”程式碼穩定的現象，就像是你能在一個破舊的老房子裡安穩地住上一輩子。
你會發現，儘管牆壁斑駁、地板鬆動，但奇怪的是，這個房子就能挺過風雨，依然屹立不倒。
這種程式碼是技術負債的結果，剛開始可能充滿bug和遺留問題，但隨著時間推移，它已經適應了並且“理順了”許多潛在的問題點，變得有點像一個“躲過風雨的老兵”。
不過，總有一天得面對技術債務的“爆發”時刻，到時再來一場重構也是必然的。下方回答摘取知乎問題“如何看待“屎山”程式碼卻異常穩定？選了一些回答。
知乎好友廖雪峰
因為屎山不是一天拉成的，它是很多人多年慢慢拉成的。
每當新人在山頂拉軟軟的新屎時，底下的屎已經凝固硬化了，強度經得起考驗。
不怕在山頂拉新屎，就怕在山腳鏟舊屎。
知乎好友洋耗子
大家都把屎山說得太好了。說得好像所有，至少大部分弄得出屎山的團隊都有特別好的測試環節能保證屎山的質量呢。
事實上根本不可能——反過來說，如果一個團隊有非常嚴謹和良好的測試流程來保障質量，那麼他們同樣大機率在做需求分析、程式碼設計以及程式碼review環節也會做得不錯，這樣的程式碼只能稱為複雜，不能稱為屎山。
屎山程式碼之所以穩定，最重要的原因是人擇原理——不穩定的屎山程式碼早就因為各種原因（通常是無法快速加功能）而被拋棄了。實際上，每一次“重構”/“重寫”，其根源動機大都是因為被某座屎山給刺激到了。
而另外兩個常見的淘汰屎山程式碼的時機是專案結束，和專案切換技術棧。
知乎好友李明陽
因為經過了足夠的測試。
工程問題就是這樣，不依賴於勞動者的高素質，而依賴於工作流程，好的工作流程可以讓領域內的大多數勞動者都可以做出質量達標的產品。
軟體測試成本遠低於其他行業，所以測試驅動的開發被更廣泛應用。
我們公司某些有幾十年歷史的大型軟體，哪怕你只修改了一行，提交程式碼後都會觸發自動化測試，把所有用例跑一遍，跑幾天都是有可能的。
看著繁瑣，但是真省心，只要用例跑完沒問題，你就可以相信這程式碼很健壯了。
自然，你還要補一些針對你的修改的測試用例，然後用例會被幾個你不認識的人評審。這樣做是為了檢查你補充的註釋和文件，如果另一個程式設計師可以不與你做任何溝通，僅憑程式碼、註釋、文件，就能理解一切，說明你的工作滿足要求了。
我剛入職的時候，總覺得前人的程式碼不優雅，總想自己改改，結果無一例外，大改之後連用例都跑不過，總有犄角旮旯的地方會出錯，然後我才理解，很多地方不是前人不想改，而是真的沒法改。
每當我看到一段程式碼很不優雅，覺得自己能寫得更好，往往不是我很強前人很弱，而是有我沒發現的坑，等我把這些坑都踩到了，我會發現，前人的方案才是最好的，我還沒人家做得好呢。多年之後，每當我評審別人的程式碼，往往我修改的，是測試用例。
我會檢查他們的用例是否合理，是否全面，只要用例質量夠高，能過，程式碼就不用看了。
知乎好友編譯船伕
羅馬不是一天建成的，屎山程式碼也一樣。
也許最初的時候，只是程式碼不那麼優美而已。慢慢的，各種需求驅動下，來來往往的各個水平的程式設計師的各種質量程式碼插入，最終形成了屎山程式碼。
然而，它經歷過了時間的檢驗，雖然爛得讓人無法下手修改，但是畢竟是需求驅動的，維持現有業務還是能勉強運轉的。
這種情況下，推倒重構需要工作量極大，在上面再繡花也是難上加難。
回到問題，實際上也談不上異常穩定，只不過是原有業務已經支援了，不改動的情況下，一般不會出什麼問題。一旦加新功能，或者嘗試重構，那就會極其不穩定。否則，也稱不上是屎山程式碼了。
知乎好友裸碼之道
boolisPrime(int nNumber){returnfalse;}你測試時，發現輸入3和5返回結果不對，那行，我改為：
boolisPrime(int nNumber){if(nNumber == 3) returntrue;if(nNumber == 5) returntrue;returnfalse;}你測試發現之前的bug修正了，但你發現輸入11、13、17不對，於是我改……
你測試時，很少發現問題，你看到程式碼時，你想砍人。—-很多祖傳“屎山”程式碼大概就是這意思。
一大波精彩評論正在襲來~
官方站點：www.linuxprobe.com
Linux命令大全：www.linuxcool.com
劉遄老師QQ：5604215
Linux技術交流群：2636170
（新群，火熱加群中……）
想要學習Linux系統的讀者可以點選"閱讀原文"按鈕來了解書籍《Linux就該這麼學》，同時也非常適合專業的運維人員閱讀，成為輔助您工作的高價值工具書！