人人都恨不得家裡有件祖上傳下來的寶貝，程序員除外。
祖傳代碼，也被稱為“屎山”，技術大牛都不敢輕易碰的東西。
初生牛犢的我，不信邪，有一天，我修改了其中一行不起眼的代碼：
後來我才明白一個道理。
牛頓說過：我看得遠，因為我站在巨人的肩膀上。
而對於我來說，是站在了這玩意兒上面：
祖傳代碼的愛恨情仇
在我的項目組裡，有一個傳奇的後端JS代碼，6000多行，沒有面向對象封裝，純靠函數。帶了二十多個形參、幾個標誌位，分別有十幾個數字狀態。
註釋？不存在的。
神奇的是，代碼在執行的時候，基本上沒太多的錯。
每一位接手過這段代碼的人，都會不約而同的發一條朋友圈，以示佩服。
直到有一天
一位“大牛”在離職前，重構了這段代碼
留下了至今都沒有修改完的bug
從那時起，我明白了一個道理：“重構祖傳代碼，就跟遷墳一樣，稍有不慎，萬劫不復！”
要重構？可以！等我不忙的時候再說
一般，我都忙
祖傳代碼，反正我是不敢動了，反倒是組裡的一哥們兒，鬧了個大笑話。
因為組裡就我們幾個人，很多事都當面說，這哥們兒也是習慣了。一天上班時，忽然大喊大叫：“這代碼誰寫的，這麼明顯的bug都能出，還不寫註釋，真的氣死人！”
隔壁的項目經理都聽到了，發話說：“那個誰，你查一下SVN記錄，查出來全公司通報，扣他年終獎。”
“那哥們兒說在查了，等一下。”
幾分鐘過後……
“不...不可能，這怎麼可能？”
所有人都被吸引了過來，原來這段代碼是這哥們兒，一年前提交的。
為了避免尷尬，這件事就沒人再提了。
每個人都討厭祖傳代碼，卻又無時不刻的生產著……
祖傳代碼裡的故事
不知不覺，5年的時間過去了，這才明白，原來祖傳代碼裡，都蘊藏著一個個“動人”的故事。
項目啟動，經理跟我說，先出個原型，再快速迭代
後來趕項目，又跟我說，先把功能做出來，以後再重構
再後來，因為重構時間會很久，經理說，加100個運維吧，一定要把故障率控制在1%以下。
期間，穿插了無數次產品經理的需求變更……
閱讀祖傳代碼，就好像在很短的時間內，要將藏在代碼中的故事，重新演繹一遍一樣，有哪個人能懂？又有哪個神仙，能改寫故事的情節？
腫瘤代碼
這樣的祖傳代碼活到現在，是有道理的，技術更新頻繁，市場變化太快，會導致產品演變，功能需求會隨之改變。在當時可能很不錯的代，隨著時間的推移，就會變成傳說中的祖傳代碼。
可惜的是，並不是所有的祖傳代碼，都是這麼“良性”，改需求什麼的，都是家常便飯，也可以理解，但有一些代碼，簡直就像項目裡的惡性腫瘤一樣。
之前看過一個故事，驚奇萬分，說的是大型爛代碼事故。大體上是這樣的：
1996年，法國的一個政府機構，請某公司開發一款軟件，但由於公司管理不善，沒有制定對應的開發規範，導致形成了一個徹頭徹尾的爛項目。
到底有多爛呢？
總共寫出了600萬行C++代碼，要知道Linux3.13版的內核代碼，除去內核驅動和架構，在kernel/裡也就13萬行而已。總共有50000多個類；受編譯器版本限制，用的C++語法很陳舊，只能在一個早就沒維護的操作系統上部署；基於CORBA採用的數據庫軟件，來自一家早就破產的公司；運行一個用戶界面，需要啟動40-50個子線程；在32臺並行的機器上，需要48小時進行編譯；沒有采用運行庫動態鏈接技術，一個可執行程序，就有好幾百兆；啟動這玩意大約需要15分鐘；啟動成功後，一般30秒-30分鐘內就會崩潰；一些感悟
幾年下來，只有兩點感悟頗深。
其實在大部分情況下，形成所謂的“祖傳代碼”，是情有可原的。趕項目、需求變更、技術更迭，個人技術水平增強，都會導致祖傳代碼的誕生。
越大的公司，“屎山”就越高，也越多。所以，公司代碼太爛，不應該成為我離職的理由，這是不負責任的表現。當然，如果是上面那個故事的，除外……
祖傳代碼很讓人討厭，因為你不得不用一些古代流行的命名方法、設計模式去修改這些東西，但我想說的是，千萬別輕易做出改變，如非必要，別碰。
最後用一張有趣的圖片，結束本文。