程式設計師最恐怖的夢魘是什麼？

　　這是Quora上的一個問題，其中Mick的回答獲得了13.5k“贊同”，他如此回憶道：

　　曾經有位心理學的博士僱我查一個BUG，程式是他的一個學生寫的，經常會出現奇怪的輸出。程式的功能是，從檔案中讀取資料，提出50個問題，進行一系列計算，然後基於這位博士的研究來得出一個分數。程式跑在大學的一臺3B2上。他給我演示了程式，確認這個Bug可以重現——每次在問題之間切換的時候，總會閃出一些奇怪的字元。我覺得這應該很簡單，所以答應了他，並且我們同意按小時付費。

　　Day1

　　我來到這臺3B2面前，用那個學生的帳號登入，找到了用C寫的原始碼，並開始測試。程式碼可讀性非常差，所有的程式碼都寫在了一行，變數名都是三個字母，而且還是隨機組合的！真慶幸我當初選擇按小時收費。我把程式碼格式化為習慣的風格，這樣看起來多少還能讀。

　　做完之後，我用curses庫移到螢幕上一個點，列印一個問題和答案，然後等待回應。但是在列印出第一行之後，出現了一些亂碼，過了大約1/2秒之後，亂碼被問題覆蓋掉。這個問題應該很容易解決，只有五個地方需要列印資訊，所有的地方都出現了一閃而過的亂碼。小意思，只要刪掉mvpwintw()應該就ok了。我刪掉之後開始編譯，覺得問題差不多解決了。但是執行的時候，干擾資訊又出現了！只是亂碼變了，但是症狀還是一樣！

　　我檢查了一下程式碼，發現竟然回到了我改之前的樣子！15個檔案，混亂的格式，三個字母的變數。當初為什麼不備份一下程式碼呢，真想射自己一槍。我再一次格式化它們，這次把程式碼放到三個檔案中，以不同的名字命名。然後備份了整個資料夾，並且將許可權設定為只讀。編譯之後，一切正常。一執行，這個資料夾中又出現了15個檔案！我改過之後的原始碼沒有被刪除，然後干擾資訊又回來了。

　　我明白了，這一定是在硬碟的某個地方的程式碼，在編譯的時候會將程式新增到我修改的程式碼中去。所以我準備搜尋一下include區域（/usr/include），因為我們用的是研究的版本，所以除了kernel別的程式碼都在機器上。標頭檔案太多了，所以在3B2上搜尋需要花一些時間。以上，就是第一天的工作了。

　　Day2

　　從磁碟的搜尋中沒有得到什麼結果，這說明這些亂碼要麼是被加密了，要麼就是在lib中的某個地方。但是我沒有搜到，我決定搜尋所有的文字檔案，這次花的時間比昨天更長，第二天就這這樣過去了。

　　Day3

　　沒有結果。字串是加密的。我只好根據所有的標頭檔案來一點一點查了。這會花費相當多的時間，我們同時還警告了學校，可能有人得到了Phelps博士計算機的root許可權。但他們卻對此並不關心，可能只是一臺實驗室的計算機吧。

　　我開啟#include檔案，卻沒有發現程式碼。後來發現這些都被編譯成一個檔案了。也沒什麼關係，畢竟我們有原始碼，大不了就重新編譯所有的庫。

　　Days4-6

　　接下來是最難的部分了，我們好不容易向學校的書呆子說明了問題。然後讓Mark（我覺得他能做Unix管理員完全是因為娶了Dean的女兒）開始學習編譯。最後他終於同意交給我來做，因為他什麼都不會。在第6天最後，編譯工作終於完成了。

　　我拿出修改之後的程式碼，重新開始編譯。一切正常，然後我執行了一下，天吶！這問題又出現了。原始碼分成了15個檔案，干擾資訊又出來了。簡直跟魔法一樣，我覺得自己被打敗了，問題肯定不在原始碼裡。Phelps博士也有點不樂意了，他覺得這麼長時間，即使重新寫一個也該完成了。“當然”，我失落地說，“你是對的，說不定重寫比較好。”“好的，我們明天開始重寫。”博士說。

　　Day7

　　見鬼去吧，我不會認輸的！我跟Phelps博士說：“你不用付給我錢了，只要給我時間，我一定要找到這個bug。”

　　Days8-14

　　我學聰明瞭，他一定是修改了一些庫，我開始研究編譯出來的彙編（雖然我之前根本就不懂彙編），從開始學習，到最後看懂彙編程式碼，花了六天。雖然根本沒發現什麼異常，完全就是在浪費時間。

　　Day 15

　　突然，我意識到，問題可能出在編譯器上，一定是。每次編譯程式碼的時候，編譯器就會往原始碼中新增干擾資訊。我以前也聽說過這種情況。

　　啊耶！我找到了！我們也有編譯器的原始碼，我查了一下，謝天謝地，終於找到了。編譯器連結器中的程式碼是這樣的：

　　1)檢測所有對fopen（）的呼叫，在開啟的檔案中查詢Phelps博士的問題，如果找到

　　2）編譯的時候，重寫15個檔案

　　3）使用這15個檔案編譯博士的程式，在連結的時候會輸出-o形式的名字

　　編譯器被這個學生修改了，以便往Phelps博士的程式中新增程式碼。

　　幾天之後，AT&T的技術支援提供了原版的編譯器和連結器程式碼，我們重新編譯，替換了被修改的編譯器和連結器。

　　但是，問題還沒有解決。編譯器被其他我們沒有的原始碼汙染了。這些程式碼存在於現在可執行的編譯器中，在編譯編譯器的時候，會加入汙染程式碼。但是它並不修改/usr/src中的程式碼，而是將其複製到一個隱藏資料夾，修改編譯器原始碼，編譯，最後刪除隱藏資料夾。AT&T發現這個問題花了好長時間。這個學生修改了編譯器，讓編譯器重新編譯的時候加入汙染程式碼。最後我們不得不從另一臺3B2機器上覆制過來編譯器的位元組碼檔案版本，才終於解決這個問題。

　　通過編譯器的程式碼我們還發現，如果編譯/sbin/login的話會加入一些後門程式碼，可以允許任何人使用特定的密碼來登入root。這臺電腦可以通過調變解調器或Tymnet接入。終於，這件事引起了校方注意。

　　這人真是個天才，不過，也太恐怖了！

---

　　其他網友回答

1. Bug只在產品中有，開發版本中卻沒有或者不可重現
2. bug觸發的機率很小很小，卻又不能小到可以忽視
3. 去改不是你寫的程式碼中的bug，原來寫程式碼的這傢伙已經離職了
4. 發生bug的地方是99.9%可靠的庫，是你絕對不會懷疑的地方
5. 幾年來很多人嘗試去修改的bug，但是沒有人成功過
6. 存在邏輯錯誤的bug，只有在執行一段時間之後才會觸發
7. debug需要特定領域的知識，正是你不懂的
8. debug的deadline很緊
9. Stack Overflow掛了
10. 在Stack Overflow上搜尋問題，發現有人一年前問了同樣的問題，但是沒有人回答。
11. 分號鍵失靈
12. 看自己一年以前的程式碼，有種“這真他媽是我寫的”的感覺
13. 庫沒有文件
14. 客戶又改需求了
15. ==寫成了=
16. IE（如果你做前端）
17. Github merge衝突
18. 在錯誤的目錄下 rm -rf
19. “My code works, I don’t know why”（這句話不需要翻譯了）
20. 開會，開會，開會……作為程式設計師讓我去死吧

---

　　那麼，你的噩夢又是什麼呢？