對於調試這一塊,我覺得是憑藉經驗的積累而不斷改善的,因此對於調試的書籍歷來沒有關注過,今天休息時間翻開了《調試九法》這本書隨便看看了,忽然以爲本身之前調試確實犯了好多錯誤,這裏算是給本身一個糾正的開始,習慣是要改變,但不能少了耐心。工具
1,閱讀手冊
我作開發以前確定也是須要閱讀手冊的,但一般只是找本身關心的地方。而後等到出錯了,回過頭來再看手冊,可是第一印象對我很重要,因此第二次看手冊會不覺地去着重看之前有印象的部分,而忽略了其餘細節部分,這是很要命的。看手冊必定要有耐心,一句一句的進行。由於細節就是解決問題的關鍵。不要覺得其餘部分沒用,由於整個流程的細節你還不懂。調試
2,製造失敗
當運行代碼時會發生間歇性的bug,這是就須要屢次製造失敗來觀察他,這裏可不是模擬失敗,有時我會猜想失敗引起的緣由,而後重構代碼來模擬bug,雖然有時會成功解決問題,可是這毫不是最合適的方式。仔細思考背後的原理,而後從頭開始一點一點進行來引起失敗。要認識到「那」是有可能發生的,不要說的那麼絕對。由於整個的真正原理你還不懂。一般在調試中,我會把調試正確的代碼中的調試語句所有刪掉來顯的代碼的「乾淨」,這毫不是一個好方法。通過調試正確的代碼要作好備份,而後再正式代碼中註釋掉或者「#ifndef」來屏蔽調試的部分,由於你確定不知道之後還會不會再次調試。code
3,不要想,多看
我喜歡想這個bug出現的緣由,我想很多數工程師有這個習慣吧。可是我認爲這是最很差的一個了,想永遠沒有觀察來的有效,雖然這可能花的時間會比想時間長不少。若是想找到故障所在,必需要找到足夠多的細節而後再判斷。找到問題後多實驗幾回不一樣的情況,而後才能真正實現穩定性。不要懼怕深刻研究,由於這才真正解決這一類問題的關鍵。還有就是不要忽略了外部調試工具的影響,示波器的探針會增長電容,打印語句會影響時間和代碼規模。猜想只是爲了肯定搜索重點目標。而後進行觀察。開發