在《程式設計師，你會從 Bug 中學習麼？》一文中，我寫了我是怎樣追蹤這些年遇到的最有趣 bug 的。最近我重新瀏覽了這所有的 194 個條目（歷時 13 年），看看我從這些 bug 中學到了學到了那些重要的經驗教訓。我分為編碼、測試和除錯三大類。

編碼

這些都是過去給我帶來棘手 bug 的問題：

1.事件順序

當處理事件時，問以下問題富有成效：事件是否可以以不同的順序到達？如果沒收到這些事件怎麼辦？如果事件在同一行出現兩次怎麼辦？即使這通常不會發生，在系統的其他部分（或互動系統）中的bug也會導致它發生。

2.處理太早

這是上述“事件順序”中的一個特殊情況，但是它已導致了一些棘手的bug，所以它自成一派。例如，如果信令資訊接收得過早，在配置和啟動程式完成之前接收，許多奇怪的行為就會發生。另一個例子，當一個連線在被放入空閒列表之前就被標記為斷開。當我們處理這個問題時，我們通常假設它處在空閒列表狀態時被標記為斷開（但是當時它為什麼沒有從這個列表上撤下？） 沒考慮到事情有時發生過早是由於我們沒有想到。

3.隱蔽故障

例如，一些最難找的的 bug 是由於出現了隱蔽故障而繼續執行而不是給出錯誤的程式碼導致的。例如，系統呼叫（如繫結）返回未檢查的錯誤程式碼。另一個例子：當遇到一個錯誤元素時，直接返回而不是給出錯誤的解析程式碼。呼叫在故障的狀態下持續了一段時間，使得除錯的難度加大。一旦故障被檢測出，最好要及時返回這個錯誤。

4.If語句

含有多個條件的If語句（if (a or b)，尤其是當巢狀時，if (x) else if (y)），給我導致了許多 bug。即使If語句在概念上很簡單，當它有多個條件需要追蹤時，很容易出錯。最近我嘗試重新把程式碼寫得簡潔，避免出現複雜的If語句。

5.Else

有一些bug的產生是由於沒有恰當地考慮如果條件為假，什麼應該發生。在幾乎所有的情況下，每個If語句都應該有個else部分。而且，如果你在If語句的一個分支中設定了一個變數，你也許應該在其他分支也設定該變數。與此相關的是標誌（flag）被設定的情況。僅僅新增設定標誌的條件很容易，但是容易忘了新增應該重新設定標誌的條件。任由永久性設定的標誌留在那裡可能會在將來導致 bug。

6.改變假設

一開始最難預防的許多bug是由不斷變化的假設引起的。例如，最初僅僅只有一個客戶，在這個假設下寫了很多程式碼。後來某個時候，設計發生了變化，允許每天有多個客戶事件。當這種情況發生，就很難改變受到新設計影響的所有情況。很容易找到顯式依賴該變化的所有項，但是難的部分是，找到隱式依賴舊設計的所有情況。例如，可能有程式碼讀取給定某一天的所有客戶事件。一個隱式的假設可能是，結果集中元素的數量絕對不會大於客戶數量。我沒有好的方法可以預防這類問題，歡迎讀者建議。

7.日誌記錄

深入瞭解程式所做的任務是至關重要的，尤其是當邏輯複雜的時候。確保新增足夠的（但也別太多）日誌記錄。那樣你就能弄清楚為什麼程式在執行它執行的任務。讓一切運轉良好時，它無關緊要。但是隻要問題發生（這不可避免），你會很慶幸你新增了合適的日誌記錄。

測試

作為一名開發者，除非進行了測試，否則我不會說完成一項功能。起碼這意味著每一行新程式碼或更改後的程式碼至少執行了一次。此外，單元測試或功能測試也很好，但不夠。新功能還必須在類似產品的環境下進行測試和探究。唯有這樣，我才可以說完成了一項功能。下面是 bug 在測試方面給予我的一些重要的經驗教訓：

8.零（zero）和空（null）

務必要以零和空（合適的情況下）來進行測試。對於字串而言，這意味著既指長度為零的字串，又指內容為空的字串。另一個例子：在傳送任何資料（零位元組）之前，測試 TCP 連線的斷開。沒有使用這些組合來測試是 bug 悄然出現的頭號原因，我在測試時是原本可以發現這些 bug 的。

9.新增和刪除

新功能常常需要能夠為系統新增新配置，比如說用於電話號碼翻譯的新配置檔案。我們會自然而然的新增一個配置檔案，來驗證功能是否正常。然而，我發現很容易忘了還要測試配置檔案的刪除。

10.錯誤處理

處理錯誤的程式碼常常很難測試。最好由自動測試來檢查錯誤處理程式碼，但有時這不可能。這種情況下，我有時採用的一招就是，臨時修改程式碼，讓錯誤處理程式碼執行。要做到這一點，最容易的方法就是反轉if語句，比如說將if語句由 error_count > 0反轉為 error_count == 0。另一個例子是誤拼資料庫列名，讓所需的錯誤處理程式碼執行。

11.隨機輸入

另一種往往能夠發現 bug 的測試方法是進行隨機輸入。例如，H.323 協議的 ASN.1 解碼可處理二進位制資料。通過傳送有待解碼的隨機性位元組，我們發現瞭解碼器中的幾個 bug。另一個例子是使用測試呼叫生成指令碼，其中呼叫持續時間、回覆延遲、第一方結束通話等都是隨機生成的內容。這些測試指令碼暴露了無數 bug，尤其是接踵而至的事件引起的干擾。

12.檢查什麼不該發生

通常測試包括檢查一些需要的行為發生。但是很容易忽略他的對立面——檢查不該發生的事確實沒發生。

13.自制工具

通常，我建立了自己的小工具來使測試更簡易。例如，當我處理面向 VoIP 的 SIP 協議時，我寫了一個小的指令碼可以返回正標題和值。這個工具使得測試許多個別場景變得簡單。另一個例子是可以呼叫 API 的命令列工具。從小的開始，逐漸新增一些需要的功能，我最終有許多有用的工具，寫自己的小工具的優勢是我得到我想要的功能。

在測試中要發現所有的bug幾乎不可能。有一次，我在一種情況下，我對處理關聯號碼做了改變，包括兩部分：路由地址字首（總是相同），和從000到999的動態分配號碼。問題是，當查詢相關性時，動態分配的數字的第一個數字在查詢之前被錯誤地刪除。所以，不是尋找637之類的號碼，你尋找的是37，而這個號碼不在表中。這意味著，它一直尋找到100，所以前100個呼叫正常，而之餘的所有900個呼叫失效。所以除非我在重新啟動之前測試了100多次，否則在測試時發現不了這個問題。

除錯

14.討論

在過去對我幫助最大的除錯方法就是與同事討論問題。我常常只要向同事描述問題，就足以認識到問題是什麼。此外，即使同事不是很熟悉相應程式碼，常常也能給出好主意，表明哪裡可能有問題。我在處理最棘手的 bug 時，與同事討論特別有效。

15.密切注意

往往是當除錯一個問題很長時間時，是因為我做了錯誤的假設。例如，我認為這個問題發生在一個特定的方法中，事實上，這個問題甚至根本不會出現在這個方法中。或者丟擲的異常並不是我認為的那個。或者我認為最新版的軟體在執行，但它其實是較老的版本。因此，一定要驗證細節，而不是假設。它使你容易看到你所期望看到的問題，而不是實際發生的問題。

16.最近的一次改動

本該執行的程式停止了，它通常是由最後的一次變動導致。有一次，最近的一次變動僅僅是日誌，但是日誌中的一個錯誤導致了更大的問題。為了讓諸如此類的迴歸更容易找到，有必要在不同的提交程式碼中實行不同的變更，並且要清楚說明變更。

17.相信使用者

有時當一個使用者反饋問題時，我的本能反應是:這不可能，他們一定搞錯了。但是我已經意識到我不應該這樣做。我也不想這樣，但更多次，事實證明他們報告的問題實際上發生了。所以這些天，我認真對待他們的反饋。當然，我仍然反覆測試所有的一切被正確地設定了。但是我碰過好多情況下，之所以發生奇怪的問題，是由於不同尋常的配置或意料之外的使用，而我的預設假設是他們是對的，程式是錯的。

18.測試修復的效果

如果你已經修復了 bug，還需要再測試。首先執行修復前的程式碼，然後觀察 bug。然後運用修復再次測試。現在 bug 的問題應該被消除了。繼續這些步驟確保它確實是一個 bug，確保你的修復已經修復這個問題。簡單但很必要。

其他心得

過去13年，我一直在記錄我遇到的最棘手的bug，很多事情發生了改變。從小的嵌入式系統，到大的電信系統，網頁系統都做過。我使用的語言包括 C++、Ruby、Java 和 Python，若干類的 bug 在我使用 C++ 的日子裡就已經不再出現了。像堆疊溢位，記憶體損壞，字串的問題以及某些形式的記憶體洩漏。

其他的問題，像迴路錯誤和極端案例，我見的少得多，因為我單元測試了更多邏輯，但這並不意味著那裡沒有 bug。這篇文章總結的經驗教訓，幫助我在編碼、測試和除錯這三個階段儘量減小破壞。如果你發現了其他的技巧或者有用的技巧來預防或者找到 bug，請在評論區留言。

打賞支援我翻譯更多好文章，謝謝！

打賞譯者