閱讀離職程序員遺留下來的垃圾源代碼是怎樣一種體驗？

01-12

公司有項目做爛了，幾個程序員離職了。被派過來接手此項目，發現坑巨大無比，源代碼爛成垃圾。

我師傅當年給我推薦了這麼一本書，讓我受益匪淺。

http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

遇到這種情況，對你深表同情。對於爛成垃圾的代碼要我維護，我的選擇是：第一、想個好借口，盡量推出去，別自找麻煩，吃力不討好，第二、實在推不掉的，一定要「醜話說前頭」，先給上司打打預防針：「這些像屎一樣的代碼，我可不一定能保證應付得了……」。並且最好算算帳，修改並重構這些代碼的代價與完全重寫的代價相比，高還是低，如果對比鮮明的話，說不定上司就會讓你另起爐灶，麻煩就解決了。

就像是做著美妙的夢，享受著美女的法式熱吻，突然醒來發現被自己狗狂舔。

更可怕的是，拿著這樣的代碼，還沒有任何文檔，也沒有什麼測試，連有什麼功能都說不清楚……

公司代碼爛的一大根源就是需求不清晰，沒有規範化標準。

不過這些爛代碼可能滿足了，某些需求，重構不是不可以，重構之前要，了解並熟悉所有業務，並且記錄下所有模塊的輸入輸出效果，重構之後要保證重構前是這個效果，重構以後還是這個效果。

一開始我以為只是看到了一個隕石坑，後來又看到了幾個隕石坑，維護了幾天，我終於明白了，我TMD是在月球表面

水平不行

加班的結果

更深層的原因：老闆觀念的問題

爛代碼算什麼。。只要能跑的不出bug都是好代碼！

閱讀然後修改沒有文檔只有幾句注釋的fortran代碼才是給人生多一種體驗的經歷

p.s.

1. 注釋里寫道：「這段是做多個三維矩陣旋轉和相乘的」，句號。然後一個和我同齡的時間戳。。。

2. 和大部分fortran歷史代碼一樣，作者都是非cs出身的研究人員

每次學生畢業的時候都會給我留下很多爛代碼，我對此已經感到習以為常了。我的原則是如果一段代碼功能是正常的，就別去看它，免得破壞好心情。要知道很多偉大的應用，也可能是用爛程序堆出來的。對於功能錯誤的段落，把它徹底重寫一遍，特有成就感。

主觀點：開始覺得自己寫的代碼是坨shi ，而這貨寫的連shi都不如...

客觀點：擦屁股的最好詮釋

那是一個周五的下午，我坐等下班，然後突然經理找我說有個需求你去處理下，原來是個用PLSQL做報表的代碼，你能想像大量的SQL查詢嵌套，並且那些表和欄位的定義我完全不知道，當時催的緊，然後我只好硬著頭皮一段一段把SQL嵌套拆開，對著系統里殘缺不齊的記錄一段一段運行比對，等改完的時候我終於明白了各大互聯網企業想去存儲過程的動機，這玩意太容易與業務緊耦合了，經常一個SQL語句佔了10多行，後續維護成本太高

無注釋，無文檔，無Test case。

而且是演算法邏輯+7層if-else 嵌套。

幾千行的邏輯處理代碼。。。。。。

我讀了2個星期，然後實在坑不下去了。。。Fair well。。。