作者：江南白衣 

     昨天翻翻《程序设计实践》的Debug一章，里面用C写的例子早已被风吹的没了颜色，不随语言流转的就只有结尾那几句经验谈。但大学里向来是连这几句话也懒得教的，一定要大家从“put print statements in the program to find the bug” 开始，和bugs共同生活几年后，自个养成条件反射式的debug习惯。

     面对Bug，正确的生理反射应当是找线索而不是直接跳到Step 2蛮干：
        一、找熟悉的模式。人应该了解自己当然也包括自己常犯的错误，还有是检查那些经常犯事的代码模块。
        二、最近改过的代码。
        三、如果错误是由特定数据和操作引起的，思考这些输入的特征。
        四、如果是系统模块输出的错误，第一时间拷下来google。(不过也要提防有些系统的输出信息完全不靠谱)

    找没找到线索，然后都要开始定位错误。
    定位的方法，是经典不过的--分而治之：注释一些代码，减少、hardcode一些输入值和中间值，函数返回值等等。
    如果没有明显的线索，可单步执行，同时察看多个变量的debug工具就要及早出场，它能让你看到程序实际的执行情况而不是你思想里早就预设的误区。
    不过，断点设在哪里，先注释、hardcode哪些代码这种深刻决定debug效率的抉择，就很讲经验和最近的运势了！

     如果埋头苦干都没有结果，那可能是思维有了误区，就该拉个人过来和你聊一下天气和这个bug啦(但是注意别拉到太笨的，鸡和鸭讲的)。又或者，再回头看看是不是一些极低级的错误，比如链接库的版本错啦，根本没有重编译啦....

     改完bug后，好习惯是再看一眼别的地方中会不会还有同类的虫虫没杀掉。

    ----延伸阅读《Code Complete 2nd》中Debugging 一章。