在空白的文本編輯器里打開(kāi)一個(gè)嶄新的文本，沒(méi)有一行代碼，出現(xiàn)在眼前的是一個(gè)充滿了無(wú)限可能和希望的項(xiàng)目?？墒牵?dāng)數(shù)千行的代碼寫(xiě)完之后，整個(gè)項(xiàng)目因?yàn)閎ug的出現(xiàn)而被壓垮了，更別說(shuō)添加什么新功能了...這也許是對(duì)程序員的最大打擊，在飽滿的熱情上澆了一盆冷水。其實(shí)，最好的軟件程序員當(dāng)然知道怎樣去發(fā)現(xiàn)并修復(fù)這些bug，在剛開(kāi)始編程的時(shí)候就通過(guò)軟件工程的最好方法來(lái)降低bug的出現(xiàn)概率。

幾乎沒(méi)有哪個(gè)程序員能夠?qū)懗鲆粋€(gè)bug都沒(méi)有的代碼，但是解決方法總是比困難多得多。多實(shí)踐和堅(jiān)毅的決心是成功的關(guān)鍵，這樣才能夠?qū)懗銮鍧嵈a，保證軟件系統(tǒng)的可靠性。

下面一起來(lái)看看這些可以鎮(zhèn)壓bug的工具箱。

1. 輸出語(yǔ)句

代碼調(diào)試的首要工具就是插入可靠地、真實(shí)的輸出語(yǔ)句。當(dāng)輸出語(yǔ)句數(shù)量龐大且不易于管理的時(shí)候，在輸出語(yǔ)句里恰當(dāng)使用記錄系統(tǒng)，這可以說(shuō)是一個(gè)等效的好方案。許多編程語(yǔ)言里都配備了現(xiàn)成的類庫(kù)，例如在Python里構(gòu)建的記錄庫(kù)。

輸出語(yǔ)句是程序員檢查數(shù)據(jù)值和變量類型最快、最簡(jiǎn)單和最直接的方式。高效的輸出語(yǔ)句能夠幫助程序員通過(guò)一段代碼來(lái)跟蹤數(shù)據(jù)流，并快速識(shí)別bug源頭。雖然先進(jìn)的調(diào)試工具有很多，但是如果你想調(diào)試一段代碼的話，這個(gè)普通的輸出語(yǔ)句的方法應(yīng)該是程序員最先考慮的方法。

2. 調(diào)試器

源代碼調(diào)試器采用了輸出語(yǔ)言方法里的邏輯推理。這樣可以讓程序員一行一行的單步執(zhí)行代碼，同時(shí)監(jiān)測(cè)從變量值到底層虛擬機(jī)整個(gè)狀態(tài)的一舉一動(dòng)。另外，大部分的編程語(yǔ)言都具有多個(gè)調(diào)試器，可以提供不同的功能，包括圖形接口、終止程序的斷點(diǎn)設(shè)置、執(zhí)行環(huán)境內(nèi)部任意代碼的實(shí)施。

在許多情況下，調(diào)試器可以說(shuō)是大材小用了，但如果合理利用的話，調(diào)試器絕對(duì)是一款高效率的工具。更多調(diào)試器的功能請(qǐng)看Python調(diào)試器：pdb。

3. Bug跟蹤系統(tǒng)

在一些比較重大的軟件項(xiàng)目里，使用bug跟蹤系統(tǒng)是很有必要的。如果沒(méi)使用bug跟蹤器，最典型的狀況就是程序員要整理以往的郵件或者是聊天記錄來(lái)查找bug，更糟糕點(diǎn)兒的就是程序員根本不記得其它東西，印象里只有一點(diǎn)bug的文檔。一旦這種情況發(fā)生，bug將必然充斥著整個(gè)代碼編程，更加嚴(yán)重的是，想要識(shí)別出這些bug并確定它們的位置是很難的。

一個(gè)簡(jiǎn)單的文本文件在項(xiàng)目里可以作為最初的bug跟蹤系統(tǒng)。隨著代碼庫(kù)的不斷增加，bug衍生出一個(gè)文本文件并不需要太長(zhǎng)的時(shí)間。有很多商業(yè)和開(kāi)源的bug跟蹤軟件提供的解決方案都是可以考慮的，選擇哪一個(gè)bug跟蹤軟件首先要明確的部分就是要確保在編程項(xiàng)目里，那些非程序人員能夠快速使用這個(gè)bug跟蹤系統(tǒng)。

4. Linter

在某些編程語(yǔ)言里，Linter可以執(zhí)行對(duì)代碼的靜態(tài)分析，以便在代碼編寫(xiě)和運(yùn)行之前識(shí)別出問(wèn)題區(qū)域；在一些其它編程語(yǔ)言里，Linter工具對(duì)于語(yǔ)法檢查和增強(qiáng)風(fēng)格是很有幫助的。編程的時(shí)候在編輯器里打開(kāi)一個(gè)Linter程序，或者是在代碼編寫(xiě)和運(yùn)行之前通過(guò)Linter傳遞代碼，這些都有利于程序員在使用軟件之前發(fā)現(xiàn)并糾正更多的錯(cuò)誤。因此，使用Linter可以幫你在節(jié)省寶貴時(shí)間的同時(shí)揪出因語(yǔ)法錯(cuò)誤、打字錯(cuò)誤或數(shù)據(jù)類型錯(cuò)誤而引起的bug源頭。

想要知道什么樣的Linter最適合你使用，看看Python的Linter工具：Pyflakes。

5. 版本控制

任何一個(gè)重大的軟件工程項(xiàng)目里都不應(yīng)該忽略使用版本控制系統(tǒng)。舉例而言，像Git，Mercurial和SVN這類的版本控制允許不同的代碼庫(kù)版本在不同的基礎(chǔ)上是可以分開(kāi)的。

不同的控制版本可以被合并到一起，因此，多個(gè)程序員可以同一時(shí)間運(yùn)行同一個(gè)代碼庫(kù)。版本控制在代碼排錯(cuò)里同樣有著舉足輕重地位，可以讓程序員回滾修改較早版本的代碼，盡可能在錯(cuò)誤出現(xiàn)之前，在代碼庫(kù)里對(duì)錯(cuò)誤進(jìn)行修復(fù)。

6. 模塊化

缺少架構(gòu)的代碼是難以修復(fù)bug的主要源頭。只要代碼易于理解，而且理論上行得通，那么對(duì)于程序員來(lái)講，找到并快速修復(fù)bug并不是什么棘手的事情。另一方面，越是重要的代碼出現(xiàn)錯(cuò)誤的幾率就越大，找到這個(gè)錯(cuò)誤相對(duì)也就比較困難。

設(shè)計(jì)軟件的組件經(jīng)常需要考慮一點(diǎn)就是所謂的代碼模塊化，代碼模塊化可以幫助程序員更好的用兩種方法來(lái)理解軟件系統(tǒng)。第一，模塊化能夠創(chuàng)造出一定層次的抽象感，在沒(méi)有完全理解所有細(xì)節(jié)的情況下也能想象出系統(tǒng)的模型。比如，程序員正在構(gòu)建一個(gè)商業(yè)系統(tǒng)，可能會(huì)考慮到信用卡處理模塊，然后觀察這個(gè)模塊和其余代碼有什么聯(lián)系，根本不用考慮信用卡處理模塊的所有詳細(xì)內(nèi)容。第二，模塊的詳細(xì)說(shuō)明，這個(gè)詳細(xì)說(shuō)明是不會(huì)和別的模塊內(nèi)容混淆的，就像每個(gè)卡只有一個(gè)卡號(hào)是一樣的。

7. 自動(dòng)化測(cè)試

單元測(cè)試和其它類型的自動(dòng)化測(cè)試跟模塊化是有很大關(guān)聯(lián)的，可以說(shuō)是相輔相承。自動(dòng)化測(cè)試就是一段代碼用特殊的輸入值來(lái)運(yùn)行軟件，以此來(lái)檢測(cè)程序運(yùn)行是否和預(yù)期的相符合。

單元測(cè)試主要是用來(lái)檢測(cè)單個(gè)功能的功能性，然而功能測(cè)試是用來(lái)檢查特殊的程序性能，并且結(jié)合單元測(cè)試來(lái)檢查軟件系統(tǒng)的整體部分。有很多測(cè)試框架可以用來(lái)編寫(xiě)測(cè)試程序，而且大部分受歡迎的測(cè)試框架都是由Kent Bent編寫(xiě)的JUnit類庫(kù)衍生而來(lái)的，Kent Bent是“測(cè)試驅(qū)動(dòng)開(kāi)發(fā)方法”最早的支持者之一。 Python標(biāo)準(zhǔn)類庫(kù)包括一個(gè)JUnit的Python版本，稱之為PyUnit或者unittest的單元測(cè)試框架。

8. 泰迪熊方法（橡皮鴨調(diào)試）

在軟件編程界，就不得不提到傳奇人物Brain Kernighan和Rob Pike，泰迪熊調(diào)試法源于一個(gè)大學(xué)計(jì)算機(jī)中心，在這里，學(xué)生們遇到神秘bug的時(shí)候就可以先把問(wèn)題解釋給這只擺在桌子上的泰迪熊聽(tīng)，然后才能向老師或助教求助。所以，有的時(shí)候只跟熊聊天也能解決問(wèn)題。這一調(diào)試方法真的很管用，以至于風(fēng)靡了整個(gè)軟件工程行業(yè)，就像打印語(yǔ)句這一方，不管那些復(fù)雜的工具如何風(fēng)起云涌，輸出語(yǔ)句這一方法仍然在今天很受歡迎。

同泰迪熊調(diào)試法相似的一種方法叫做橡皮鴨調(diào)試法，當(dāng)你在向這只始終保持沉默的橡皮鴨子解釋的過(guò)程中，你會(huì)發(fā)現(xiàn)你的想法、觀點(diǎn)、思路和實(shí)際的代碼相偏離了，于是你也就找到了代碼中的bug。一旦一個(gè)問(wèn)題被充分地描述了它的細(xì)節(jié)，那么解決方法也是顯而易見(jiàn)的。你覺(jué)得這個(gè)方法太“愚蠢”，太“弱智”了？是的，看上去，會(huì)這樣做的人腦子好像是有點(diǎn)毛病。不過(guò)，我要告訴你的是，這個(gè)方法的確有效。因?yàn)?，這就是“Code Review”的雛形！

9. 編寫(xiě)代碼注釋

注釋的功能就是在更易于理解的層次上解釋代碼的編寫(xiě)目的，盡可能多寫(xiě)一些：每行代碼是干什么的，怎么去完成，這些問(wèn)題都應(yīng)該在通讀代碼之后很容易找到答案才行。另外，給各個(gè)功能和變量取合理的名稱也有助于簡(jiǎn)化代碼實(shí)施的過(guò)程。在代碼行下面的空白處填寫(xiě)注釋來(lái)回答為什么要使用特殊的實(shí)現(xiàn)功能，或者一段代碼怎樣和程序的其余部分互動(dòng)等等。

編寫(xiě)詳細(xì)的注釋可以說(shuō)是軟件工程里一步可靠地檢驗(yàn)步驟，即使是在沒(méi)有bug的代碼里也是同樣受用。這樣，就算bug出現(xiàn)了也不用擔(dān)心，注釋會(huì)幫你節(jié)省數(shù)小時(shí)的排錯(cuò)時(shí)間。

10. 編寫(xiě)文檔

代碼注釋是程序員以簡(jiǎn)單的方式和個(gè)人的觀點(diǎn)編寫(xiě)的，而編寫(xiě)軟件文檔是用來(lái)描述軟件系統(tǒng)的功能性，同時(shí)用戶也可以看到這些軟件文檔。根據(jù)軟件類型的不同，文檔可以用來(lái)詳述程序界面、圖形界面或者工作流程。

編寫(xiě)文檔還有一個(gè)好處就是，可以展示你對(duì)軟件系統(tǒng)的理解程度，指出軟件系統(tǒng)不夠完善的部分或者有可能是bug源頭的部分。

更多信息請(qǐng)查看IT技術(shù)專欄