在《Learning From Your Bugs》一文中，我寫了關于我是如何追蹤我所遇到的一些最有趣的bug，最近，我回顧了我所有的194個條目（從13歲開始），看看有什么經驗教訓是我可以學習的，下面是我總結的最重要的經驗教訓，包括編碼，測驗和除錯三個方面，
編碼
下面這些都是我經歷過的會導致難點bug的問題：
1.事件順序，在處理事件時，提出下列問題會很有成效：事件可以以不同的順序到達嗎？如果我們沒有接收到此事件會怎么樣？如果此事件接連發生兩次會怎么樣？哪怕通常不會發生，但系統（或互動系統）其他部分的bug可能會導致事件發生呢，
2.過早，這是第一點“事件順序”的一個特例，但它確實會引起一些棘手的bug，因此我把它單獨拎出來說明，例如，如果信令訊息在配置和啟動程式完成之前就被過早接收，那么可能就會有很多奇怪的行為發生，另一個例子：連接在被放進空閑串列之前就被標記為down，在除錯這類問題時，我們總是假定在空閑串列中的時候連接被設定為down（但當時為什么不把它放到串列外面呢？），這是我們思考的不足，沒有考慮到有時候事情會過早發生，
3.悄無聲息的故障，一些最難跟蹤的bug有部分是由那些靜靜失敗并擴展而不是拋出錯誤的代碼所導致的，例如，沒有檢查代碼卻回傳錯誤的系統呼叫（如bind），又如：決議代碼在它遇到錯誤元素的時候只是回傳而非拋出錯誤，在錯誤狀態中持續了一段時間的呼叫，會使除錯變得更難，最好一旦檢測到故障就回傳錯誤，
4.If，有若干條件的if陳述句，if (a 或 b) ，特別是當有鏈接的時候， if (x) else if (y)，都給我引發了很多bug，即使if陳述句在概念上很簡單，但當有多個條件要跟蹤的時候依然很容易出錯，這些天，我嘗試重寫代碼使之更簡單，以避免處理復雜的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的技術方法，歡迎不
譯文鏈接：http://www.codeceo.com/article/13-years-bug.html
英文原文：Lessons From 13 Years of Bugs
翻譯作者：碼農網 – 小峰
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/33741.html
標籤：其他