debug经验一二三
作者：
江南白衣
昨天翻翻《程序设计实践》的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 一章。
昨天翻翻《程序设计实践》的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 一章。