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

這是 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 接入。終於，這件事引起了校方注意。

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

其他網友回答 

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

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