在軟件行業中，個人覺得每個Coder、Leader（那些當了Leader以後就不需要Code的除外）都應該除了具有良好的編碼能力以外，最為主要的就是Debug的能力要堅實。千萬不要告訴我Debug工作是Tester和QA的事情，首先你要認識到Debug的能力是一個並不簡單的能力，能幫助你提高你的開發能力，加快開發速度，節約開發成本；其次你更應該知道，你所掌握的Debug的能力和技術並不可能搶去Tester或者QA的飯碗，他們做的工作更仔細、全面，更富有創造力。由於本人數年來一直使用VC6，所以下面使用的觀點和相關的描述都是從VC出發的，肯定有所偏頗、錯誤之處，還望各位看官不吝啬地指出，本人定虛心接受，共同討論，共同學習，共同進步。個人覺得Debug能力包括以下三個個方面：
1、良好的編碼習慣，良好的邏輯結構能力，對Bug的預見能力。一個成熟的程序員，應該有一個良好的編程習慣，不僅需要有良好的編碼格式規范，更為需要的是對於程序中的邏輯實現時候有一種良好的結構。編程其實就是數據和邏輯的集合，數據的處理較為簡單，或者說是需要的邏輯思維能力比較少，當算法邏輯要在數據上實現的時候，同一種邏輯，讓不同的程序員來實現可能有各種各樣的不同實現結構，從這個角度來說，這裡所說的“良好的編碼習慣”就應該指的是對於邏輯實現時候使用的良好的編程結構，一個好的編程結構應該是能預防錯誤的發生，對錯誤的預見和錯誤出現以後的錯誤處理與異常處理的良好安排。也許有人說這不好辦嗎？每個邏輯判斷的地方添加條件判斷或者異常處理不就行了？個人覺得不是那麼回事，過多的if、assert、ASSERT等語句或者是宏，尤其是並列的if語句需要耗費很多判斷、執行的時間，對於一個子程序（函數），尤其是調用頻率比較頻繁的子程序（函數），一次浪費了一點點時間，多次、頻繁地調用浪費的時候就顯得可觀了，所以並不是if語句使用的多，程序出錯的可能性就小，過猶不及！如果確實需要使用多個if語句進行條件判斷，最好能使用嵌套的if語句，逐步的縮小判斷范圍，這樣消耗的時間要比並列的if語句要小，還要注意的是if語句的條件判斷也不是萬能的；assert、ASSERT等判斷宏也不是萬能的，它會造成Debug和Release版本在響應速度和最終的編譯結果的不同，對於一些關注於性能、響應速度的程序，所造成的影響是不可忽視的。不過開發過程中的調試階段倒是提倡使用這些宏來發現算法錯誤和不足。另外對於異常處理段的使用，個人覺得能不用異常處理的地方盡量不要使用異常處理，除非當某個錯誤發生以後導致程序不能繼續執行或者是崩潰的時候才使用異常，有時候你能使用異常處理，將發生錯誤的程序繼續執行下去，但是可能產生的最後結果並不是客戶所需要或者是期望的，這樣就容易讓客戶產生質疑：你是不是在程序中做了什麼手腳？這也讓你失去了獲得Bug發生的前提狀況信息，從而失去了一次修改Bug的機會，所以說有時候當程序發生錯誤時，僅僅彈出一個MessageBox提示一些信息，然後關閉程序，也不失為一個好的辦法。
2、編碼過程中的調試跟蹤和錯誤定位能力。這個能力主要就是在開發過程中，當自己在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等等），輸入相關的錯誤提示信息，也許搜索到類似問題的網頁，也許別人也遇到過同樣或者同類的問題，其他人所提供的答案就是你所需要的，或者能給你以提示、啟發的！
3、對事後發生的Bug能有良好的感知能力。當一個Bug出現的時候，優秀的程序員能根據Bug發生的前提和Bug發生的時間點、程序中的位置，很好的感知到Bug可能發生在哪一個函數或者哪幾個函數中，是什麼情況導致Bug的出現的，並且能夠很快的定位錯誤並Fix這個錯誤。這種能力使用的地方往往是程序已經Release了，已經被客戶使用了，在使用的過程中發生了Bug，客戶向你“傾訴”時。那麼怎麼才能有這樣的能力呢？也許很多的這種能力都是在你不斷的摔倒，被經理P了N次以後，所積累起來的經驗，所以說這也是一種痛苦以後所獲得的快樂的能力，它需要你對自己所做的軟件產品的結構、運行條件、運行原理和相關的涉及部分有很好的理解、掌握。有的時候多在網站上看看別人的經歷也能有所收獲。
在以上的三種能力中，第一種能力主要在於態度和思維能力，後兩種則偏向於學習能力和經驗的積累；個人覺得第一種最為重要，所謂的“態度決定一切”嘛，呵呵。
最後向你推薦幾本關於調試的書籍：
1、《Writing Clean Code——Microsoft Techniques for Developing Bug-free C Programs》（中文版譯作《編程精粹——Microsoft編寫優質無錯C程序秘訣》或者叫做《零錯誤程序》）——這是一本出版很早的書，現在也許在書店中都看不到了，但是你要相信此書的作者Steve Maguire（曾是Microsoft資深的程序員，參加了Excel在多個平台下的開發和移植工作）所提供的許多防錯、排錯、測試的准則還是能讓人從中獲益非淺的。作者將每章的要點都和自己實際工作經歷相結合，提供了翔實的例子和相關代碼，使用的語言更是幽默風趣，讓人讀起來不會感覺晦澀難懂，尤其是每章結束部分提供的練習和思考題更是貼合實際，發人深省。也就是這些原因才使得這本書經久不衰，一直為廣大程序所喜愛，所廣泛地討論。至今尚未能見到能與之相媲美的書籍。網上所流傳的林銳博士所著的《高質量C++編程指南》和《軟件工程思想》在深度和廣度上與之相比也顯得遜色不少！
2、《Debugging Windows Programs》（中文版譯作《Windows程序調試》，中國電力出版社出版）——這是一本現在在書店很為流行的一本書。此書使用的語言比較樸實、易懂，也許是譯者精心處理的結果，敘述習慣比較符合國人口味。這本書主要包含調試策略、調試工具、調試技術三部分，本書主要介紹的是在VC這個IDE、編譯器下開發程序所應有的一些技術。看完此書你肯定會更為深入的了解MFC，了解結構化異常和C++異常的區別和聯系，了解怎麼調試多線程程序，怎麼調試COM程序，怎麼調試內存，怎麼調試繪圖程序等等。不管你是自認為有多年的開發經驗的開發高手，還是剛剛入門的初學者，相信只要你耐心的看完此書，你一定會和我一樣深深的感歎一句：原來VC的調試功能這麼強大！如果早點看到這本書就好了！
3、《Debugging Applications》（本人尚未見到中文版）——這本書主要介紹的是VC和VB的調試，其中VC的調試占到70%-80%左右。本書也分為三部分：Debug的形式，強有力的Debug，Debug的工具和技術。其中有部分內容和上一本書所說的相同。但是這本書還是提供了很多新的東西：介紹了遠程調試，提供了一些新的工具使用例子的說明，介紹了更多的底層的東西，甚至涉及匯編的相關信息的閱讀和理解。在閱讀了上一本書以後，如果你還想提高，這本書是你不錯的選擇。
第一本書主要就是培養大家第一種Debug能力的，後兩本書是培養大家第二種Debug能力的，對於第三種能力主要還是要靠經驗的積累。
至於為什麼會在本文的結束部分使用那段版權申明，主要是因為前段時間我發現我以前寫的一些文章被轉載在個別的網站上而沒有注明出處和作者，甚至個別人在自己的Blog上直接將我的文章Copy、Paste為自己的作品。本人甚是BS類似的人和相關的網站，因為他們可能連最為簡單的測試和驗證都沒有進行就相信了我所說的一切，甚至連最明顯的遺漏的單詞和語句都沒有添加上，導致我比較拙劣的文筆暴露在大庭廣眾之下，使我身心受到很大的傷害，呵呵，所以此次添加了這個版權申明。添加這個版權申明並不表示我反對轉載、Copy/Paste我的文章，我甚至還期望你們這樣做，但是請在做這件事情之前，仔細閱讀、思考我的文章中所說的東西，修改、驗證其中你認為錯誤或者不足的地方以免因為我的知識的不足而寫出的文章，加上你們的強大的傳播能力，導致更多的人，尤其是初學者誤入歧途，多走彎路，那就違背了我寫這些文章的初衷了。Top
歡迎大家指教，提出不同觀點，相互討亂，相互學習，共同提高！Top
收藏Top
關於文中所提及的第一本書和第三本書都有電子版，如果哪位兄弟能提供FTP，本人將其上傳，造福更多兄弟就更好了！Top
馬人口Top
馬人口？？？？Top
寒~~~我原意是寫mark……Top
我記得有一本叫做《程序調試思想與實踐》的外國人寫的書，也不錯。不過買了以後，看了才1半。Top
到現在看了才一半，發現那本書還不錯。，Top
mark
Top
馬人口Top
markTop
MARKTop
收藏Top
不錯啊，spTop
馬人口Top
幾天沒見樓主上CSDN了啊，一回來就給大家帶好東西啊
贊一個Top
upTop
摟主高人啊，謝謝！Top
markTop
是有很多天沒有上CSDN了，到了新公司以後比較忙！
就是偶爾來一次也是忙裡偷閒，偷偷的上！呵呵。Top
寫的不錯！
你可以把第3本書的電子版發給我麼？謝謝！[email protected]
不好意思mail寫錯了。應該是：[email protected]
來來來，支持一把Top
支持...
很多時候花在調試上的時間比編碼要多得多,還要痛苦, 調試確實是很有學問的.Top
寫的不錯！
Top
c++程序調試Top
大哥，是你的帖，能不頂嗎？ 馬人口，哈哈~~Top
好東西，支持一下！Top
詳細看了兩遍大哥你的文章，挺有同感，但是小弟水平肯定沒法和大哥比.....
不敢發表什麼高論，只是想說一下自己常用的方法。
針對有很多時候，錯誤都針對不同的客戶才出現（同一套系統），所以我除了上述方法外，更趨向於采用寫文件進行Debug的方式，把可能出現問題的地方通過日志來定位（由於有些問題不是馬上能出現，出現的時間也很Random），還有就是在程序中定義一個Log的Dlg，用於實時的調試日志。
方法有點笨，但是對於處理實際的情況還不錯。
就說那麼多，聆聽大家的高見。Top
頂
我一直覺得自己寫的代碼，就應該自己排錯！！Top
好帖沒人頂呢，我頂~
收藏Top
支持..Top
支持.Top
定Top
COPYTop
收藏Top
mark 先Top
to ayanamiwww:
這裡沒有什麼所謂的水平高低，每個人都有自己的長處、優點，每個人都有自己擅長的某一方面，只是有的人願意總結，拿出來和別人分享、討論。我覺得知識唯有不斷的論證才能進步。軟件這個行業的理論、思想發展的很快，有些以前正確的理論，在現金未必是正確的，一些對你是正確的理論，由於其約束性，對於別人未必是正確的。所以需要分享、論證！Top
建議共享一下資源哈[電子書]Top
順道問個問題哈。
這個問題已經困擾我很久了我也嘗試過了很多方法，但都未果，希望大家能指點一下方向。
問題是這樣的：我想做個微軟播放器全屏時上下兩個彩色條，當鼠標移動時，它自動彈出，此時你可以控制暫停/播放等，當鼠標不動後一秒左右，它自動隱藏，我不知道他的那個彩色條是個什麼控件之類的，能幫我看看嗎？謝謝Top
支持Top
不知道該怎麼申明作者名呢~~Top
建議共享一下資源哈[電子書]
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
如果哪位兄弟能提供FTP，本人將其上傳，如果是發送郵件，那就算了，呵呵，新公司的管理比較嚴。
不知道該怎麼申明作者名呢~~
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
使用：
CSDN vcleaner (我沒當大哥很久了.......)Top
學習！收藏Top
markTop
我甚是贊同樓主的觀點，
事實上，我認為調試水平最能反映一個程序員的功力高低。
我的意思是，寫點兒代碼誰都會，關鍵是需要培養調試能力。Top
upTop
好Top
jf,upTop
贊同樓主的觀點。
補充一句：一個設計良好的數據結構，會給程序設計和以後的調試帶來事半功倍的效果。
一家之言，歡迎批評指正。Top
樓主的觀點基本贊同。
不過遺漏了一個重要方面，匯編調試。
很多bug不進行匯編跟蹤是看不出來的，比如有的bug在Debug版下沒有問題，在release版下有問題，怎麼辦？手工下斷點，進行匯編調試，找出問題。還有一種情況，release程序正常運行，但在某個時刻發生異常崩潰，你怎麼辦？看drwtsn32的故障轉儲文件，也要分析匯編代碼。
對於軟件調試，如果不考慮軟件邏輯/算法的問題，僅就軟件本來說可以按照下面的步驟進行的：
代碼調試（編譯能否通過）-->內存調試（數據處理是否正確，堆棧是否正常）--->寄存器調試（寄存器內容是否正確）。
另外強烈推薦VC，除了一些系統級調試不能做之外，其他的問題都可以解決。Top
mark!Top
好貼,頂!Top
markTop
我覺得你自己寫的程序沒有理由調不好，就這麼簡單
當然前提是系統設計、模塊組織合理，對調試工具熟悉，當然有些錯誤像數組越界很隱蔽，需要吃一塹長一智，編碼和調試其實是一個有機整體，光管寫不管能不能運行那叫編程嗎？！Top
我不知道數組越界的這種發現方法，據我了解一般是破壞堆棧後，引發GP錯誤，從而發現問題。不知道你說的這個字節的內容是什麼？誰來判斷？什麼規則？
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
我的理解GP錯誤是針對操作系統的。在當前的操作系統下，每個進程有4G的進程空間，但是有相當一部分是不能直接有進程訪問的，具體的分配參見《Windows核心編程》，這時候如果訪問了這個空間就會產生GP錯誤。但是數組越界缺不是這麼回事，它訪問的空間是仍然可以由進程訪問的，但是無意間越界了，這時候一般不會出現問題，只是響應的值可能是錯誤的，這種錯誤可以通過在數組兩端設置兩個越界的判斷內存Byte來判斷，具體就是在這兩個Byte中寫入特別的數值，作為判斷標志。具體原理和內容參考《零錯誤程序》！！
至於mfc消息的問題，在下覺得原因是函數實現出問題了，導致壓棧錯誤。比如消息函數的本來原型是LRESULT Onxxxx(WPARAM w, LPARAM l),可是我們通常因為不需要參數傳遞，就簡化為void Onxxxx（）,這樣就會出問題的，mfc的機制對於自定義消息，要求兩個參數，而現在沒有，壓棧的時候就會出問題。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
那你想過為什麼在Debug模式下沒有問題嗎？同樣也需要壓棧！Top
歡迎象 cxf1976() 這樣的同志參與，共同討論，共同進步。大家也不要盡信我所說的一切都是正確的。即使現在是正確的也不能保證以後是正確的，畢竟一切都是在改變中的，編程的基礎就是OS所提供的API接口，OS的內核都在改變，沒有什麼是不改變的，呵呵。Top
關於數組訪問越界，類似於下面的這個程序：
以下三條輸出語句分別輸出什麼？[C易]
char str1[] = "abc";
char str2[] = "abc";
const char str3[] = "abc";
const char str4[] = "abc";
const char* str5 = "abc";
const char* str6 = "abc";
cout << boolalpha << ( str1==str2 ) << endl; // 輸出什麼？
cout << boolalpha << ( str3==str4 ) << endl; // 輸出什麼？
cout << boolalpha << ( str5==str6 ) << endl; // 輸出什麼？
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
關於：
很多bug不進行匯編跟蹤是看不出來的，比如有的bug在Debug版下沒有問題，在release版下有問題，怎麼辦？手工下斷點，進行匯編調試，找出問題。還有一種情況，release程序正常運行，但在某個時刻發生異常崩潰，你怎麼辦？看drwtsn32的故障轉儲文件，也要分析匯編代碼。
對於軟件調試，如果不考慮軟件邏輯/算法的問題，僅就軟件本來說可以按照下面的步驟進行的：
代碼調試（編譯能否通過）-->內存調試（數據處理是否正確，堆棧是否正常）--->寄存器調試（寄存器內容是否正確）。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
這個觀點我是很同意的，但是現在有多少人能熟練使用匯編呢？我也不能。如果在Release模式下出現問題，可以使用MAP文件定位錯誤的位置。呵呵，參考：
http://www.vckbase.com/document/vIEwdoc/?id=908
http://www.vckbase.com/document/vIEwdoc/?id=1473Top
就象我帖子中所說的“有的時候多在網站上看看別人的經歷也能有所收獲。”建議大家到下面的URL去看看，仔細體會一下，肯定能學到很多東西：
http://www.vckbase.com/document/listdoc.ASP?mclsid=23&sclsid=2303Top
樓主有沒關於WinDbg的資料啊？Top
WinDbg的幫助文件就很好了，呵呵，有時間仔細的看看！
Top也可以直接從vckbase下載：
http://www.vckbase.com/tools/debug/dbg_x86_6.2.13.1.exeTop
Windows 2000的調試符號和Windbg：
http://www.microsoft.com/Windows2000/downloads/tools/symbols/download.ASPTop
markTop
markTop
樓主說語言的風格真讓我感覺熟悉
哈哈
認識一下高人
轉載地址: http://tb.blog.csdn.Net/TrackBack.ASPx?PostId=1623220
