程序員調試能力和相關書籍

在軟件行業中，我的以爲每一個Coder、Leader（那些當了Leader之後就不須要Code的除外）都應該除了具備良好的編碼能力之外，最爲主要的就是Debug的能力要堅實。千萬不要告訴我Debug工做是Tester和QA的事情，首先你要認識到Debug的能力是一個並不簡單的能力，能幫助你提升你的開發能力，加快開發速度，節約開發成本；其次你更應該知道，你所掌握的Debug的能力和技術並不可能搶去Tester或者QA的飯碗，他們作的工做更仔細、全面，更富有創造力。因爲本人數年來一直使用VC6，因此下面使用的觀點和相關的描述都是從VC出發的，確定有所偏頗、錯誤之處，還望各位看官不吝嗇地指出，本人定虛心接受，共同討論，共同窗習，共同進步。我的以爲Debug能力包括如下三個個方面：

 

一、良好的編碼習慣，良好的邏輯結構能力，對Bug的預見能力。一個成熟的程序員，應該有一個良好的編程習慣，不只須要有良好的編碼格式規範，更爲須要的是對於程序中的邏輯實現時候有一種良好的結構。編程其實就是數據和邏輯的集合，數據的處理較爲簡單，或者說是須要的邏輯思惟能力比較少，當算法邏輯要在數據上實現的時候，同一種邏輯，讓不一樣的程序員來實現可能有各類各樣的不一樣實現結構，從這個角度來講，這裏所說的「良好的編碼習慣」就應該指的是對於邏輯實現時候使用的良好的編程結構，一個好的編程結構應該是能預防錯誤的發生，對錯誤的預見和錯誤出現之後的錯誤處理與異常處理的良好安排。也許有人說這很差辦嗎？每一個邏輯判斷的地方添加條件判斷或者異常處理不就好了？我的以爲不是那麼回事，過多的if、assert、ASSERT等語句或者是宏，尤爲是並列的if語句須要耗費不少判斷、執行的時間，對於一個子程序（函數），尤爲是調用頻率比較頻繁的子程序（函數），一次浪費了一點點時間，屢次、頻繁地調用浪費的時候就顯得可觀了，因此並非if語句使用的多，程序出錯的可能性就小，過猶不及！若是確實須要使用多個if語句進行條件判斷，最好能使用嵌套的if語句，逐步的縮小判斷範圍，這樣消耗的時間要比並列的if語句要小，還要注意的是if語句的條件判斷也不是萬能的；assert、ASSERT等判斷宏也不是萬能的，它會形成Debug和Release版本在響應速度和最終的編譯結果的不一樣，對於一些關注於性能、響應速度的程序，所形成的影響是不可忽視的。不過開發過程當中的調試階段卻是提倡使用這些宏來發現算法錯誤和不足。另外對於異常處理段的使用，我的以爲能不用異常處理的地方儘可能不要使用異常處理，除非當某個錯誤發生之後致使程序不能繼續執行或者是崩潰的時候才使用異常，有時候你能使用異常處理，將發生錯誤的程序繼續執行下去，可是可能產生的最後結果並非客戶所須要或者是指望的，這樣就容易讓客戶產生質疑：你是否是在程序中作了什麼手腳？這也讓你失去了得到Bug發生的前提情況信息，從而失去了一次修改Bug的機會，因此說有時候當程序發生錯誤時，僅僅彈出一個MessageBox提示一些信息，而後關閉程序，也不失爲一個好的辦法。

 

二、編碼過程當中的調試跟蹤和錯誤定位能力。這個能力主要就是在開發過程當中，當本身在Build程序，Run起來之後，居然發生了Bug或者是Memory Leak，這時候就須要你使用各類工具進行調試跟蹤了。首先你要相信VC不只是一個很好的IDE，也是一個很好的Debug工具，其提供的調用棧、條件斷點、數據斷點、反彙編等工具足夠強大，足夠應付日常的Bug，可是如今不少的程序員，包括一些自稱爲老程序員的也未必能很好的使用這些工具，尤爲是條件斷點和數據斷點（在下面介紹的第二本書中有詳細的使用說明）。當VC不能知足你的要求的時候你就須要使用其餘的工具了，例如：SmartChecker，BoundChecker，Purify，SoftICE等等了。從這個角度來講，這裏的「調試跟蹤能力」不只是程序員對Bug的定位能力，更爲主要的仍是對於調試工具的掌握、使用的能力。「磨刀不誤砍柴工」，在開發以前或者開發閒暇時，好好的研究一下一些開發、調試工具不愧爲一種好的提高這種能力的好辦法。能靜下心來思考一下這些工具的工做原理就更好了，這樣不只能幫助你在編程的時候預見Bug，而且對你提升你的編程技巧也會有所幫助。例如VC中的程序在Debug模式下爲何能發現數組訪問越界？這是由於在Debug模式下，在分配數組所佔用的內存時候，編譯器在數組內存的兩端分別加入了一個字節的越界判斷內存。這也就是爲何不少的MFC程序在使用自定義消息的時候在Debug模式下沒有錯誤而在Release模式下發生錯誤的緣由了。這裏我還想說一說我最喜歡作的兩種調試方法：當Bug出現的時候，首先肯定Bug的位置，而後：A、註釋掉可能致使Bug的段落，在須要取得數據值的地方直接提供一個合理的值，而後看看程序是否能正確運行，如此循環往復，逐步縮小範圍，最終找出Bug所在；B、若是Bug被定位在一個小的功能、子程序或者函數中，可使用新建一個Test工程，在一個徹底「乾淨」的環境下，對此功能、子程序或者函數進行測試，找出Bug所在。此節最後我想說的就是利用你的網絡。當一個Bug出現時，你也許感到茫然，也許感到無從下手，這時候你就能夠利用的你網絡資源，使用強大的搜索引擎（好比Google、Baidu等等），輸入相關的錯誤提示信息，也許搜索到相似問題的網頁，也許別人也遇到過一樣或者同類的問題，其餘人所提供的答案就是你所須要的，或者能給你以提示、啓發的！

 

三、對過後發生的Bug能有良好的感知能力。當一個Bug出現的時候，優秀的程序員能根據Bug發生的前提和Bug發生的時間點、程序中的位置，很好的感知到Bug可能發生在哪個函數或者哪幾個函數中，是什麼狀況致使Bug的出現的，而且可以很快的定位錯誤並Fix這個錯誤。這種能力使用的地方每每是程序已經Release了，已經被客戶使用了，在使用的過程當中發生了Bug，客戶向你「傾訴」時。那麼怎麼纔能有這樣的能力呢？也許不少的這種能力都是在你不斷的摔倒，被經理P了N次之後，所積累起來的經驗，因此說這也是一種痛苦之後所得到的快樂的能力，它須要你對本身所作的軟件產品的結構、運行條件、運行原理和相關的涉及部分有很好的理解、掌握。有的時候多在網站上看看別人的經歷也能有所收穫。

 

在以上的三種能力中，第一種能力主要在於態度和思惟能力，後兩種則偏向於學習能力和經驗的積累；我的以爲第一種最爲重要，所謂的「態度決定一切」嘛，呵呵。

 

最後向你推薦幾本關於調試的書籍：

 

一、《Writing Clean Code——Microsoft Techniques for Developing Bug-free C Programs》（中文版譯做《編程精粹——Microsoft編寫優質無錯C程序祕訣》或者叫作《零錯誤程序》）——這是一本出版很早的書，如今也許在書店中都看不到了，可是你要相信此書的做者Steve Maguire（曾是Microsoft資深的程序員，參加了Excel在多個平臺下的開發和移植工做）所提供的許多防錯、排錯、測試的準則仍是能讓人從中獲益非淺的。做者將每章的要點都和本身實際工做經歷相結合，提供了翔實的例子和相關代碼，使用的語言更是幽默風趣，讓人讀起來不會感受晦澀難懂，尤爲是每章結束部分提供的練習和思考題更是貼合實際，發人深省。也就是這些緣由才使得這本書經久不衰，一直爲廣大程序所喜好，所普遍地討論。至今還沒有能見到能與之相媲美的書籍。網上所流傳的林銳博士所著的《高質量C++編程指南》和《軟件工程思想》在深度和廣度上與之相比也顯得遜色很多！

 

二、《Debugging Windows Programs》（中文版譯做《Windows程序調試》，中國電力出版社出版）——這是一本如今在書店很爲流行的一本書。此書使用的語言比較樸實、易懂，也許是譯者精心處理的結果，敘述習慣比較符合國人口味。這本書主要包含調試策略、調試工具、調試技術三部分，本書主要介紹的是在VC這個IDE、編譯器下開發程序所應有的一些技術。看完此書你確定會更爲深刻的瞭解MFC，瞭解結構化異常和C++異常的區別和聯繫，瞭解怎麼調試多線程程序，怎麼調試COM程序，怎麼調試內存，怎麼調試繪圖程序等等。無論你是自認爲有多年的開發經驗的開發高手，仍是剛剛入門的初學者，相信只要你耐心的看完此書，你必定會和我同樣深深的感嘆一句：原來VC的調試功能這麼強大！若是早點看到這本書就行了！

 

三、《Debugging Applications》（本人還沒有見到中文版）——這本書主要介紹的是VC和VB的調試，其中VC的調試佔到70%-80%左右。本書也分爲三部分：Debug的形式，強有力的Debug，Debug的工具和技術。其中有部份內容和上一本書所說的相同。可是這本書仍是提供了不少新的東西：介紹了遠程調試，提供了一些新的工具使用例子的說明，介紹了更多的底層的東西，甚至涉及彙編的相關信息的閱讀和理解。在閱讀了上一本書之後，若是你還想提升，這本書是你不錯的選擇。

 

第一本書主要就是培養你們第一種Debug能力的，後兩本書是培養你們第二種Debug能力的，對於第三種能力主要仍是要靠經驗的積累。

 

我如今就看到這三本書是比較好的書，若是你以爲有其餘的比較好的相關書籍或者相關信息請告知我。在確定這幾本書對你的開發過程會有所幫助的前提下，另外我想說的就是即便你看了這幾本書你也不會編寫出徹底沒有Bug的程序，畢竟Bug的種類和發生的狀況實在是有不少的客觀和主觀因素，不可能徹底杜絕。程序設計是一門實踐性很強的工做，惟有在工做、實踐過程當中總結教訓，總結經驗才能不斷提升。祝你們在得到知識，積累經驗的過程當中少走彎路，大踏步的前進！！！

 

（本文版權歸做者全部，如需轉載請註明做者和出處，不然也能夠轉載，但千萬不要標註爲你我的的做品，不然產生的一切後果請自負，尤爲是被BS、被扔臭雞蛋的時候，千萬不要怨恨我，同時做者我還保留BS你的權利，^_^）

 

轉自：http://blog.csdn.net/vcleaner/article/details/378591