程序員調試能力和相關書籍
要想練氣宗：看WINDOWS編程後深入淺出MFC！
要想練劍宗：直接看孫鑫的視屏，講的很好！
程序員調試能力和相關書籍
在軟件行業中，個人覺得每個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能力的，對於第三種能力主要還是要靠經驗的積累。
我現在就看到這三本書是比較好的書，如果你覺得有其他的比較好的相關書籍或者相關信息請告知我。在肯定這幾本書對你的開發過程會有所幫助的前提下，另外我想說的就是即使你看了這幾本書你也不會編寫出完全沒有Bug的程序，畢竟Bug的種類和發生的情況實在是有很多的客觀和主觀因素，不可能完全杜絕。程序設計是一門實踐性很強的工作，唯有在工作、實踐過程中總結教訓，總結經驗才能不斷提高。祝大家在獲得知識，積累經驗的過程中少走彎路，大踏步的前進！！！