在《Learning From Your Bugs》一文中， 我寫了關於我是如何追蹤我所遇到的一些最有趣的bug。 最近， 我回顧了我所有的194個條目（從13歲開始）， 看看有什麼經驗教訓是我可以學習的。 下面是我總結的最重要的經驗教訓， 包括編碼， 測試和調試三個方面。
下面這些都是我經歷過的會導致難點bug的問題：
1.事件順序。 在處理事件時， 提出下列問題會很有成效：事件可以以不同的順序到達嗎？如果我們沒有接收到此事件會怎麼樣？如果此事件接連發生兩次會怎麼樣？哪怕通常不會發生， 但系統（或交互系統）其他部分的bug可能會導致事件發生呢。
2.過早。 這是第一點“事件順序”的一個特例， 但它確實會引起一些棘手的bug， 因此我把它單獨拎出來說明。 例如， 如果信令消息在配置和啟動程式完成之前就被過早接收， 那麼可能就會有很多奇怪的行為發生。 另一個例子：連接在被放進空閒清單之前就被標記為down。
3.悄無聲息的故障。 一些最難跟蹤的bug有部分是由那些靜靜失敗並擴展而不是拋出錯誤的代碼所導致的。 例如， 沒有檢查代碼卻返回錯誤的系統調用（如bind）。 又如：解析代碼在它遇到錯誤元素的時候只是返回而非拋出錯誤。 在錯誤狀態中持續了一段時間的調用， 會使調試變得更難。 最好一旦檢測到故障就返回錯誤。
4.If。 有若干條件的if語句， if (a 或 b) ， 特別是當有連結的時候， if (x) else if (y)， 都給我引發了很多bug。 即使if語句在概念上很簡單， 但當有多個條件要跟蹤的時候依然很容易出錯。
5.Else。 有一些bug是因為沒有正確考慮到如果條件為false時會發生什麼而引起的。 幾乎在所有的情況下， 都應該有一個else部分來應對每一條if語句。 此外， 如果你在if語句的分支中設置變數， 那麼或許你在另一個分支中也要設置。 與此種情況相關的是標記被設置的情況。 只添加用於設置的標記的條件不難， 但是很容易忘了添加當標記應該再次重置時的條件。 留下一個永遠設置的標誌可能會導致之後接連不斷的bug。
6.改變假設。 許多一開始最難預防的bug是因為改變了假設所造成的。 例如， 在開始時， 可能每天只有一個客戶事件。 於是很多代碼是在這樣的假設下寫下的。
7.日誌記錄。 視覺化程式做什麼至關重要， 特別是當邏輯很複雜的時候。 確保補充足夠多的（但不要太多）日誌記錄， 這樣你就可以說明為什麼程式要這麼做。 如果一切正常， 那也沒關係， 但要是有問題發生， 你會很慶倖自己添加了這些日誌。
作為一個開發人員， 直到要測試了我才會去處理功能。 至少， 這意味著每一行新的或改變了的代碼行至少已經被執行過一次。 此外， 單元測試和功能測試都很不錯， 但還不夠。 新的功能也必須進行測試， 並在類似於產品的環境中探索。 只有這樣， 我才能說我完成了一個功能。 下面是我經歷過的bug所教會我的關於測試的一些重要的經驗教訓：
8.零和null。 如果可行的話， 確保總是用零和null來測試。 對於字串， 這意味著要測試長度為零的字串以及字串為null兩種情況。 又如：測試TCP連接的斷開， 要在發送資料給它發送之前。 不使用這些組合方法測試是導致bug出現的首位原因。
9.添加和刪除。 通常， 新的功能包括能夠添加新的配置到系統中——例如， 一個用於手機號碼轉換的新的設定檔。測試它能否添加新的設定檔是很自然的。但是，我發現我們很容易忘記去測試刪除設定檔是不是同樣ok。
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，並且此次修復的確可以解決這個問題。簡單而有必要。
其他觀察結果在這13年來我一直在跟蹤我所遇到的最棘手的bug，很多事情由此而改變。我工作過小的嵌入式系統，大的電信系統以及基於web的系統。我使用過C ++，Ruby，Java和Python。在工作于C++時所遇到的幾類bug已經完全消失，像堆疊溢位，記憶體損壞，字串問題和某種形式的記憶體洩漏。
其他問題，如迴圈錯誤和邊界情況，我看到的要少得多。但是，這並不意味著那裡沒有bug。這篇文章中的經驗教訓旨在説明減少編碼，測試和調試三個階段的bug。如果大家有什麼有用的預防和發現bug的技術方法，歡迎不吝指導。
挖礦搬磚不如IT碼農，輕鬆轉行還看蝸牛學院。
蝸牛學院 專注於IT職業教育，輕鬆轉行，簡學易懂；免費試學，親身體驗；商業項目親自操刀，與名企零距離接觸；應屆生就業薪資6000起，年薪10萬不是事，漲幅絕比房價高。
一個用於手機號碼轉換的新的設定檔。測試它能否添加新的設定檔是很自然的。但是，我發現我們很容易忘記去測試刪除設定檔是不是同樣ok。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，並且此次修復的確可以解決這個問題。簡單而有必要。
其他觀察結果在這13年來我一直在跟蹤我所遇到的最棘手的bug，很多事情由此而改變。我工作過小的嵌入式系統，大的電信系統以及基於web的系統。我使用過C ++，Ruby，Java和Python。在工作于C++時所遇到的幾類bug已經完全消失，像堆疊溢位，記憶體損壞，字串問題和某種形式的記憶體洩漏。
其他問題，如迴圈錯誤和邊界情況，我看到的要少得多。但是，這並不意味著那裡沒有bug。這篇文章中的經驗教訓旨在説明減少編碼，測試和調試三個階段的bug。如果大家有什麼有用的預防和發現bug的技術方法，歡迎不吝指導。
挖礦搬磚不如IT碼農，輕鬆轉行還看蝸牛學院。
蝸牛學院 專注於IT職業教育，輕鬆轉行，簡學易懂；免費試學，親身體驗；商業項目親自操刀，與名企零距離接觸；應屆生就業薪資6000起，年薪10萬不是事，漲幅絕比房價高。