10個調試和排錯的小建議

在空白的文本編輯器裏打開一個嶄新的文本，沒有一行代碼，出如今眼前的是一個充滿了無限可能和但願的項目。但是，當數千行的代碼寫完以後，整個項目由於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源頭的部分。