作者：江南白衣 

     昨天翻翻《程序設(shè)計(jì)實(shí)踐》的Debug一章，里面用C寫的例子早已被風(fēng)吹的沒了顏色，不隨語言流轉(zhuǎn)的就只有結(jié)尾那幾句經(jīng)驗(yàn)談。但大學(xué)里向來是連這幾句話也懶得教的，一定要大家從“put print statements in the program to find the bug” 開始，和bugs共同生活幾年后，自個(gè)養(yǎng)成條件反射式的debug習(xí)慣。

     面對Bug，正確的生理反射應(yīng)當(dāng)是找線索而不是直接跳到Step 2蠻干：
        一、找熟悉的模式。人應(yīng)該了解自己當(dāng)然也包括自己常犯的錯(cuò)誤，還有是檢查那些經(jīng)常犯事的代碼模塊。
        二、最近改過的代碼。
        三、如果錯(cuò)誤是由特定數(shù)據(jù)和操作引起的，思考這些輸入的特征。
        四、如果是系統(tǒng)模塊輸出的錯(cuò)誤，第一時(shí)間拷下來google。(不過也要提防有些系統(tǒng)的輸出信息完全不靠譜)

    找沒找到線索，然后都要開始定位錯(cuò)誤。
    定位的方法，是經(jīng)典不過的--分而治之：注釋一些代碼，減少、hardcode一些輸入值和中間值，函數(shù)返回值等等。
    如果沒有明顯的線索，可單步執(zhí)行，同時(shí)察看多個(gè)變量的debug工具就要及早出場，它能讓你看到程序?qū)嶋H的執(zhí)行情況而不是你思想里早就預(yù)設(shè)的誤區(qū)。
    不過，斷點(diǎn)設(shè)在哪里，先注釋、hardcode哪些代碼這種深刻決定debug效率的抉擇，就很講經(jīng)驗(yàn)和最近的運(yùn)勢了！

     如果埋頭苦干都沒有結(jié)果，那可能是思維有了誤區(qū)，就該拉個(gè)人過來和你聊一下天氣和這個(gè)bug啦(但是注意別拉到太笨的，雞和鴨講的)。又或者，再回頭看看是不是一些極低級的錯(cuò)誤，比如鏈接庫的版本錯(cuò)啦，根本沒有重編譯啦....

     改完bug后，好習(xí)慣是再看一眼別的地方中會不會還有同類的蟲蟲沒殺掉。

    ----延伸閱讀《Code Complete 2nd》中Debugging 一章。