在《Learning From Your Bugs》一文中，我寫了關(guān)于我是如何追蹤我所遇到的一些最有趣的bug。最近，我回顧了我所有的194個(gè)條目（從13歲開始），看看有什么經(jīng)驗(yàn)教訓(xùn)是我可以學(xué)習(xí)的。下面是我總結(jié)的最重要的經(jīng)驗(yàn)教訓(xùn)，包括編碼，測(cè)試和調(diào)試三個(gè)方面。

　　編碼

　　下面這些都是我經(jīng)歷過(guò)的會(huì)導(dǎo)致難點(diǎn)bug的問(wèn)題：

　　1.事件順序。在處理事件時(shí)，提出下列問(wèn)題會(huì)很有成效：事件可以以不同的順序到達(dá)嗎？如果我們沒(méi)有接收到此事件會(huì)怎么樣？如果此事件接連發(fā)生兩次會(huì)怎么樣？哪怕通常不會(huì)發(fā)生，但系統(tǒng)（或交互系統(tǒng)）其他部分的bug可能會(huì)導(dǎo)致事件發(fā)生呢。

　　2.過(guò)早。這是第一點(diǎn)“事件順序”的一個(gè)特例，但它確實(shí)會(huì)引起一些棘手的bug，因此我把它單獨(dú)拎出來(lái)說(shuō)明。例如，如果信令消息在配置和啟動(dòng)程序完成之前就被過(guò)早接收，那么可能就會(huì)有很多奇怪的行為發(fā)生。另一個(gè)例子：連接在被放進(jìn)空閑列表之前就被標(biāo)記為down。在調(diào)試這類問(wèn)題時(shí)，我們總是假定在空閑列表中的時(shí)候連接被設(shè)置為down（但當(dāng)時(shí)為什么不把它放到列表外面呢？）。這是我們思考的不足，沒(méi)有考慮到有時(shí)候事情會(huì)過(guò)早發(fā)生。

　　3.悄無(wú)聲息的故障。一些最難跟蹤的bug有部分是由那些靜靜失敗并擴(kuò)展而不是拋出錯(cuò)誤的代碼所導(dǎo)致的。例如，沒(méi)有檢查代碼卻返回錯(cuò)誤的系統(tǒng)調(diào)用（如bind）。又如：解析代碼在它遇到錯(cuò)誤元素的時(shí)候只是返回而非拋出錯(cuò)誤。在錯(cuò)誤狀態(tài)中持續(xù)了一段時(shí)間的調(diào)用，會(huì)使調(diào)試變得更難。最好一旦檢測(cè)到故障就返回錯(cuò)誤。

　　4.If。有若干條件的if語(yǔ)句，if （a 或 b） ，特別是當(dāng)有鏈接的時(shí)候， if （x） else if （y），都給我引發(fā)了很多bug。即使if語(yǔ)句在概念上很簡(jiǎn)單，但當(dāng)有多個(gè)條件要跟蹤的時(shí)候依然很容易出錯(cuò)。這些天，我嘗試重寫代碼使之更簡(jiǎn)單，以避免處理復(fù)雜的if語(yǔ)句。

　　5.Else。有一些bug是因?yàn)闆](méi)有正確考慮到如果條件為false時(shí)會(huì)發(fā)生什么而引起的。幾乎在所有的情況下，都應(yīng)該有一個(gè)else部分來(lái)應(yīng)對(duì)每一條if語(yǔ)句。此外，如果你在if語(yǔ)句的分支中設(shè)置變量，那么或許你在另一個(gè)分支中也要設(shè)置。與此種情況相關(guān)的是標(biāo)記被設(shè)置的情況。只添加用于設(shè)置的標(biāo)記的條件不難，但是很容易忘了添加當(dāng)標(biāo)記應(yīng)該再次重置時(shí)的條件。留下一個(gè)永遠(yuǎn)設(shè)置的標(biāo)志可能會(huì)導(dǎo)致之后接連不斷的bug。

　　6.改變假設(shè)。許多一開始最難預(yù)防的bug是因?yàn)楦淖兞思僭O(shè)所造成的。例如，在開始時(shí)，可能每天只有一個(gè)客戶事件。于是很多代碼是在這樣的假設(shè)下寫下的。但是后來(lái)，設(shè)計(jì)改變了，允許每天有多個(gè)客戶事件了。發(fā)生這種情況時(shí)，很難改變新設(shè)計(jì)影響到的所有情況。找到關(guān)于改變的所有顯式依賴關(guān)系不難，難的是要找到所有隱性依賴于舊的設(shè)計(jì)的情況。例如，可能會(huì)有獲取給定某一天所有客戶事件的代碼。其中的隱含假設(shè)是結(jié)果集永遠(yuǎn)不會(huì)超過(guò)客戶的數(shù)量。關(guān)于這方面的問(wèn)題我也沒(méi)有很好的策略方法，如果各位有的話，還請(qǐng)不吝賜教。

　　7.日志記錄。可視化程序做什么至關(guān)重要，特別是當(dāng)邏輯很復(fù)雜的時(shí)候。確保補(bǔ)充足夠多的（但不要太多）日志記錄，這樣你就可以說(shuō)明為什么程序要這么做。如果一切正常，那也沒(méi)關(guān)系，但要是有問(wèn)題發(fā)生，你會(huì)很慶幸自己添加了這些日志。

　　測(cè)試

　　作為一個(gè)開發(fā)人員，直到要測(cè)試了我才會(huì)去處理功能。至少，這意味著每一行新的或改變了的代碼行至少已經(jīng)被執(zhí)行過(guò)一次。此外，單元測(cè)試和功能測(cè)試都很不錯(cuò)，但還不夠。新的功能也必須進(jìn)行測(cè)試，并在類似于產(chǎn)品的環(huán)境中探索。只有這樣，我才能說(shuō)我完成了一個(gè)功能。下面是我經(jīng)歷過(guò)的bug所教會(huì)我的關(guān)于測(cè)試的一些重要的經(jīng)驗(yàn)教訓(xùn)：

　　8.零和null。如果可行的話，確保總是用零和null來(lái)測(cè)試。對(duì)于字符串，這意味著要測(cè)試長(zhǎng)度為零的字符串以及字符串為null兩種情況。又如：測(cè)試TCP連接的斷開，要在發(fā)送數(shù)據(jù)給它發(fā)送之前。不使用這些組合方法測(cè)試是導(dǎo)致bug出現(xiàn)的首位原因。

　　9.添加和刪除。通常，新的功能包括能夠添加新的配置到系統(tǒng)中——例如，一個(gè)用于手機(jī)號(hào)碼轉(zhuǎn)換的新的配置文件。測(cè)試它能否添加新的配置文件是很自然的。但是，我發(fā)現(xiàn)我們很容易忘記去測(cè)試刪除配置文件是不是同樣ok。

　　10.錯(cuò)誤處理。處理錯(cuò)誤的代碼往往是難以測(cè)試的。最好有能檢查錯(cuò)誤處理代碼的自動(dòng)測(cè)試，但有時(shí)這是不可能的。我有時(shí)會(huì)使用的一招是臨時(shí)修改代碼，使得錯(cuò)誤處理代碼運(yùn)行起來(lái)。要做到這一點(diǎn)最簡(jiǎn)單的方法是反轉(zhuǎn)if語(yǔ)句——例如，從if error_count 》 0改成error_count == 0。另一個(gè)例子是拼錯(cuò)數(shù)據(jù)庫(kù)列名，從而導(dǎo)致期望的錯(cuò)誤處理代碼運(yùn)行。

　　11.隨機(jī)輸入。通常，揭露bug測(cè)試的一種測(cè)試方法是使用隨機(jī)輸入。例如，H.323協(xié)議的ASN.1解碼使用二進(jìn)制數(shù)據(jù)操作。通過(guò)發(fā)送隨機(jī)字節(jié)去解碼，我們發(fā)現(xiàn)了解碼器中的幾個(gè)bug。另一個(gè)例子是用測(cè)試呼叫來(lái)生成腳本，此時(shí)呼叫持續(xù)時(shí)間，接聽延遲，第一方掛斷等等都是隨機(jī)生成的。這些測(cè)試腳本會(huì)暴露許多bug，特別是一起發(fā)生的事件會(huì)產(chǎn)生并攏干擾。

　　12.檢查不應(yīng)該發(fā)生的動(dòng)作。通常測(cè)試包括檢查期望動(dòng)作是不是發(fā)生了。但我們很容易忽視相反的情況——忘記檢查不應(yīng)該發(fā)生的動(dòng)作是不是的確沒(méi)有發(fā)生。

　　13.擁有工具。我創(chuàng)建了自己的小工具，以使得測(cè)試更加簡(jiǎn)單。例如，當(dāng)我用VoIP SIP協(xié)議工作時(shí)，我寫了一個(gè)能夠用正是我想要的標(biāo)題和值回復(fù)的小腳本。這個(gè)工具使得測(cè)試很多邊界情況變得容易起來(lái)。另一個(gè)例子是可以進(jìn)行API調(diào)用的一個(gè)命令行工具。通過(guò)啟動(dòng)逐漸添加所需小功能，我得到了一些非常有用的工具。自己寫工具的好處是，我得到的正是我想要的。

　　在測(cè)試中發(fā)現(xiàn)所有的bug，那絕對(duì)是不可能的。有一個(gè)案例中，我更改了數(shù)字相關(guān)性的處理，數(shù)字由兩個(gè)部分組成：路由地址前綴（通常是不變的），以及從000到999動(dòng)態(tài)分配的數(shù)字。問(wèn)題在于當(dāng)找到相關(guān)性時(shí)，動(dòng)態(tài)分配的數(shù)字的第一個(gè)數(shù)字會(huì)在呈現(xiàn)在表格中之前遭到誤刪。也就是說(shuō)637變成了37。這意味著，到100之前它都是可以工作的，因此，前面100個(gè)電話是正常的，但是接下來(lái)的900個(gè)都是失敗。所以，除非我在重新啟動(dòng)之前能夠測(cè)試超過(guò)100次（事實(shí)是我沒(méi)有），否則我在測(cè)試時(shí)就不會(huì)發(fā)現(xiàn)這個(gè)問(wèn)題。

　　調(diào)試

　　14.討論。幫助我最多的調(diào)試技術(shù)是與同事討論問(wèn)題。通常情況下，只是和同事說(shuō)明問(wèn)題，就會(huì)讓我意識(shí)到問(wèn)題的癥結(jié)。此外，即使他們不是很熟悉有問(wèn)題的代碼，他們也往往能提出一些好點(diǎn)子。與同事討論在處理最難的bug時(shí)特別有效。

　　15.密切關(guān)注。通常，如果調(diào)試問(wèn)題花了很長(zhǎng)時(shí)間，往往是因?yàn)槲易隽隋e(cuò)誤的假設(shè)。例如，我認(rèn)為問(wèn)題發(fā)生在某一方法中，但事實(shí)卻是它甚至從來(lái)沒(méi)有到達(dá)那個(gè)方法。或者，被拋出的異常不是我以為的那個(gè)。或者，我認(rèn)為軟件的最新版本上正在運(yùn)行，但其實(shí)是一個(gè)舊版本。因此，一定要核實(shí)細(xì)節(jié)，而不是假設(shè)。人們更容易看到自己希望看到的東西，而不是事實(shí)。

　　16.最近的變化。當(dāng)曾經(jīng)可以正常工作的東西停止工作，那么這通常是因?yàn)樽罱淖兊臇|西所導(dǎo)致的。在一個(gè)案例中，最近的改變只是日志記錄，但是日志中的錯(cuò)誤卻導(dǎo)致了一個(gè)更大的問(wèn)題。為了更容易找到這種回歸，承認(rèn)不同的提交會(huì)導(dǎo)致不同的變化，以及清楚說(shuō)明這些更改會(huì)有所裨益。

　　17.相信用戶。有時(shí)，當(dāng)用戶報(bào)告問(wèn)題的時(shí)候，我的本能反應(yīng)是，“這是不可能的。一定是他們做錯(cuò)了什么事”。但我學(xué)會(huì)了不再用這種方式去回應(yīng)。更多的時(shí)間，事實(shí)往往證明，他們所報(bào)告的的確是實(shí)際發(fā)生的情況。因此，這些天，我開始接受他們所報(bào)告的內(nèi)容的表明價(jià)值。當(dāng)然，我依然會(huì)仔細(xì)檢查一切是否被正確地設(shè)置等等。我見(jiàn)過(guò)很多這樣的情況，讓我明白，因?yàn)椴粚こ５呐渲没蛞饬现獾挠梅ǘ鴮?dǎo)致不可思議的事情的發(fā)生，而我默認(rèn)的假設(shè)是，他們是正確的，程序是錯(cuò)誤的。

　　18.測(cè)試修復(fù)。如果bug修復(fù)已準(zhǔn)備就緒，那就必須進(jìn)行測(cè)試。首先在修復(fù)前運(yùn)行代碼，并觀察該bug。然后應(yīng)用修復(fù)并重復(fù)測(cè)試案例。到此為止錯(cuò)誤行為應(yīng)消失。遵循這些步驟可以確保它確實(shí)是一個(gè)bug，并且此次修復(fù)的確可以解決這個(gè)問(wèn)題。簡(jiǎn)單而有必要。

　　其他觀察結(jié)果

　　在這13年來(lái)我一直在跟蹤我所遇到的最棘手的bug，很多事情由此而改變。我工作過(guò)小的嵌入式系統(tǒng)，大的電信系統(tǒng)以及基于web的系統(tǒng)。我使用過(guò)C ++，Ruby，Java和Python。在工作于C++時(shí)所遇到的幾類bug已經(jīng)完全消失，像堆棧溢出，內(nèi)存損壞，字符串問(wèn)題和某種形式的內(nèi)存泄漏。

　　其他問(wèn)題，如循環(huán)錯(cuò)誤和邊界情況，我看到的要少得多。但是，這并不意味著那里沒(méi)有bug。這篇文章中的經(jīng)驗(yàn)教訓(xùn)旨在幫助減少編碼，測(cè)試和調(diào)試三個(gè)階段的bug。如果大家有什么有用的預(yù)防和發(fā)現(xiàn)bug的技術(shù)方法，歡迎不吝指導(dǎo)。