在空白的文本編輯器裏打開一個嶄新的文本，沒有一行代碼，出現在眼前的是一個充滿了無限可能和希望的項目。可是，當數千行的代碼寫完之後，整個項目因爲bug的出現而被壓垮了，更別說添加什麼新功能了...這也許是對程序員的最大打擊，在飽滿的熱情上澆了一盆冷水。其實，最好的軟件程序員當然知道怎樣去發現並修復這些bug，在剛開始編程的時候就通過軟件工程的最好方法來降低bug的出現概率。
幾乎沒有哪個程序員能夠寫出一個bug都沒有的代碼，但是解決方法總是比困難多得多。多實踐和堅毅的決心是成功的關鍵，這樣才能夠寫出清潔代碼，保證軟件系統的可靠性。
下面一起來看看這些可以鎮壓bug的工具箱。
1. 輸出語句
代碼調試的首要工具就是插入可靠地、真實的輸出語句。當輸出語句數量龐大且不易於管理的時候，在輸出語句裏恰當使用記錄系統，這可以說是一個等效的好方案。許多編程語言裏都配備了現成的類庫，例如在Python裏構建的記錄庫。
輸出語句是程序員檢查數據值和變量類型最快、最簡單和最直接的方式。高效的輸出語句能夠幫助程序員通過一段代碼來跟蹤數據流，並快速識別bug源頭。雖然先進的調試工具有很多，但是如果你想調試一段代碼的話，這個普通的輸出語句的方法應該是程序員最先考慮的方法。
2. 調試器
源代碼調試器採用了輸出語言方法裏的邏輯推理。這樣可以讓程序員一行一行的單步執行代碼，同時監測從變量值到底層虛擬機整個狀態的一舉一動。另外，大部分的編程語言都具有多個調試器，可以提供不同的功能，包括圖形接口、終止程序的斷點設置、執行環境內部任意代碼的實施。
在許多情況下，調試器可以說是大材小用了，但如果合理利用的話，調試器絕對是一款高效率的工具。更多調試器的功能請看Python調試器：pdb。
3. Bug跟蹤系統
在一些比較重大的軟件項目裏，使用bug跟蹤系統是很有必要的。如果沒使用bug跟蹤器，最典型的狀況就是程序員要整理以往的郵件或者是聊天記錄來查找bug，更糟糕點兒的就是程序員根本不記得其它東西，印象裏只有一點bug的文檔。一旦這種情況發生，bug將必然充斥着整個代碼編程，更加嚴重的是，想要識別出這些bug並確定它們的位置是很難的。
一個簡單的文本文件在項目裏可以作爲最初的bug跟蹤系統。隨着代碼庫的不斷增加，bug衍生出一個文本文件並不需要太長的時間。有很多商業和開源的bug跟蹤軟件提供的解決方案都是可以考慮的，選擇哪一個bug跟蹤軟件首先要明確的部分就是要確保在編程項目裏，那些非程序人員能夠快速使用這個bug跟蹤系統。
4. Linter
在某些編程語言裏，Linter可以執行對代碼的靜態分析，以便在代碼編寫和運行之前識別出問題區域；在一些其它編程語言裏，Linter工具對於語法檢查和增強風格是很有幫助的。編程的時候在編輯器裏打開一個Linter程序，或者是在代碼編寫和運行之前通過Linter傳遞代碼，這些都有利於程序員在使用軟件之前發現並糾正更多的錯誤。因此，使用Linter可以幫你在節省寶貴時間的同時揪出因語法錯誤、打字錯誤或數據類型錯誤而引起的bug源頭。
想要知道什麼樣的Linter最適合你使用，看看Python的Linter工具：Pyflakes。
5. 版本控制
任何一個重大的軟件工程項目裏都不應該忽略使用版本控制系統。舉例而言，像Git，Mercurial和SVN這類的版本控制允許不同的代碼庫版本在不同的基礎上是可以分開的。
不同的控制版本可以被合併到一起，因此，多個程序員可以同一時間運行同一個代碼庫。版本控制在代碼排錯裏同樣有着舉足輕重地位，可以讓程序員回滾修改較早版本的代碼，儘可能在錯誤出現之前，在代碼庫裏對錯誤進行修復。
6. 模塊化
缺少架構的代碼是難以修復bug的主要源頭。只要代碼易於理解，而且理論上行得通，那麼對於程序員來講，找到並快速修復bug並不是什麼棘手的事情。另一方面，越是重要的代碼出現錯誤的機率就越大，找到這個錯誤相對也就比較困難。
設計軟件的組件經常需要考慮一點就是所謂的代碼模塊化，代碼模塊化可以幫助程序員更好的用兩種方法來理解軟件系統。第一，模塊化能夠創造出一定層次的抽象感，在沒有完全理解所有細節的情況下也能想象出系統的模型。比如，程序員正在構建一個商業系統，可能會考慮到信用卡處理模塊，然後觀察這個模塊和其餘代碼有什麼聯繫，根本不用考慮信用卡處理模塊的所有詳細內容。第二，模塊的詳細說明，這個詳細說明是不會和別的模塊內容混淆的，就像每個卡只有一個卡號是一樣的。
7. 自動化測試
單元測試和其它類型的自動化測試跟模塊化是有很大關聯的，可以說是相輔相承。自動化測試就是一段代碼用特殊的輸入值來運行軟件，以此來檢測程序運行是否和預期的相符合。
單元測試主要是用來檢測單個功能的功能性，然而功能測試是用來檢查特殊的程序性能，並且結合單元測試來檢查軟件系統的整體部分。有很多測試框架可以用來編寫測試程序，而且大部分受歡迎的測試框架都是由Kent Bent編寫的JUnit類庫衍生而來的，Kent Bent是“測試驅動開發方法”最早的支持者之一。 Python標準類庫包括一個JUnit的Python版本，稱之爲PyUnit或者unittest的單元測試框架。
8. 泰迪熊方法（橡皮鴨調試）
在軟件編程界，就不得不提到傳奇人物Brain Kernighan和Rob Pike，泰迪熊調試法源於一個大學計算機中心，在這裏，學生們遇到神祕bug的時候就可以先把問題解釋給這隻擺在桌子上的泰迪熊聽，然後才能向老師或助教求助。所以，有的時候只跟熊聊天也能解決問題。這一調試方法真的很管用，以至於風靡了整個軟件工程行業，就像打印語句這一方，不管那些複雜的工具如何風起雲涌，輸出語句這一方法仍然在今天很受歡迎。
同泰迪熊調試法相似的一種方法叫做橡皮鴨調試法，當你在向這隻始終保持沉默的橡皮鴨子解釋的過程中，你會發現你的想法、觀點、思路和實際的代碼相偏離了，於是你也就找到了代碼中的bug。一旦一個問題被充分地描述了它的細節，那麼解決方法也是顯而易見的。你覺得這個方法太“愚蠢”，太“弱智”了？是的，看上去，會這樣做的人腦子好像是有點毛病。不過，我要告訴你的是，這個方法的確有效。因爲，這就是“Code Review”的雛形！
9. 編寫代碼註釋
註釋的功能就是在更易於理解的層次上解釋代碼的編寫目的，儘可能多寫一些：每行代碼是幹什麼的，怎麼去完成，這些問題都應該在通讀代碼之後很容易找到答案才行。另外，給各個功能和變量取合理的名稱也有助於簡化代碼實施的過程。在代碼行下面的空白處填寫註釋來回答爲什麼要使用特殊的實現功能，或者一段代碼怎樣和程序的其餘部分互動等等。
編寫詳細的註釋可以說是軟件工程裏一步可靠地檢驗步驟，即使是在沒有bug的代碼裏也是同樣受用。這樣，就算bug出現了也不用擔心，註釋會幫你節省數小時的排錯時間。
10. 編寫文檔
代碼註釋是程序員以簡單的方式和個人的觀點編寫的，而編寫軟件文檔是用來描述軟件系統的功能性，同時用戶也可以看到這些軟件文檔。根據軟件類型的不同，文檔可以用來詳述程序界面、圖形界面或者工作流程。
編寫文檔還有一個好處就是，可以展示你對軟件系統的理解程度，指出軟件系統不夠完善的部分或者有可能是bug源頭的部分。