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

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

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

1. 輸出語句

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

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

2. 調(diào)試器

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

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

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

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

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

4. Linter

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

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

5. 版本控制

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

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

6. 模塊化

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

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

7. 自動化測試

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

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

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

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

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

9. 編寫代碼注釋

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

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

10. 編寫文檔

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

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