亞馬遜的工程師形容說他們的程式碼:“一座很大的屎山，你見過的最大的山，每次你想修正一個bug，你的工作就是爬到屎山的正中心去”。

剛入職的時候，熟悉專案程式碼，經常碰到各種奇形怪狀的程式碼，有且不限於：各種進不去的分支，各種奇葩邏輯，各種風格不統一的編碼風格，各種我也形容不上來但是看著很蛋疼的程式碼。。。每當問起老員工這裡為什麼這樣實現時，他都會漏出一副深邃的表情：別問我，我來時就這樣了，歷史遺留問題。。。

至於如何對待，我舉個例子。我們程式碼中有一行程式碼，在一個奇奇怪怪的地方設了個奇奇怪怪的標誌量，然後後面一個註釋：

// 位置不能動，不然時序就都亂了。

作為一個萌新我當然乖乖滴沒去動它，直到有一期新需求，這個標誌量的位置出現了點小問題，然後我就嘗試性地把這句話往後挪了一小下，然後程式從頭錯到腳指甲。在體會到前輩的用心良苦後，我又在那個註釋下面加了一句：經驗證，真的不能動。。。

樓主你好，個人經驗“祖傳程式碼”有兩種情況分別是：有效解決問題無需重複造輪子、程式之初未能有效規劃造成的“惡果”。

在實際開發中，有些東西是不用重複編寫只需要拿來用即可。比如資料庫操作模組，底層網路套接處理，經過沉澱穩定強壯的底層框架等。這些通用性較強且效能尚可的模組都可以作為“祖傳模組”。

有些情況猿猿們接手專案，發現幾年前的模組存在問題、但是稍微修改卻會導致血崩。類似的這些模組我們不會直接修改，像螞蟥一樣疼卻不能拔出來。

很多核心程式碼一直在用，比如Excel裡的一些標準計算公式，可能自誕生開始就那樣了。

所謂的祖傳程式碼，只是因為程式碼的更新維護工作出現斷層，掌握相關程式碼邏輯的人已經不在了，新人又不敢碰，就變成了補洞的方式，圍繞這坨原始程式碼，導致邏輯越來越複雜，更加沒人動，惡性迴圈。

雖然導致這種問題的原因很多，但最終一定是公司在程式碼的管理上有問題。國內很多公司都注重結果導向，忽略了程式碼本身的維護狀況，也不會有專門的團隊來監管程式碼編寫標準和文件的維護。最後就是越來越冗餘，每個人都想推倒重做。

如今網際網路公司更是嚴重，時代變化快，儘早上線才是王道，其他不重要。於是，很多企業的程式碼都是屎，但只要測試工作到位，程式碼可以正常工作就行。

微服務的概念也是某種程度上緩解了這種問題，儘量把業務邏輯拆分成可維護的模組，獨立的模組保持完整性，就可以讓整體看起來更加易於維護。

哈哈哈哈，這是一個很有趣的問題，因為第一代程式，會出現比較多BUG，然後為了修補這個BUG，找不出原因的程式設計師，會一直寫一些奇奇怪怪程式碼，可能會取消某一個判斷又出現新的判斷，如此類推，某一個判斷可能已經被多次取消了，反正就是改了就影響很多程式碼，很容易發生系統崩塌，所以一些十幾年的程式，有的公司寧願開發新的同樣功能的系統，都不願意改，改了就會很容易系統崩塌，影響使用者體驗。

前人挖的坑，不要隨意去填——你只能去看看而已。如果你想去填坑，那你就是被坑的那個人~~~哈哈哈，開個玩笑！~~~祖傳程式碼的說法，只是說說而已。真正的正規公司，運營在數年以上的，都會有自己的程式碼庫以及複用件，新入職的員工需要事先熟悉熟悉而已。不過，你真的想要大規模的重構，注意——請慎重！請極端慎重！絕對是吃力不討好！還不如重新寫一遍。但重寫一遍，你老闆花得起供養你的成本麼？