最近在编程的时候经常出bug，在解决bug的时候却又因为还在沿用着原始的printf方法，导致查找bug和分析问题的速度变得极其的慢，浪费了好多时间，工作效率显得特别的低下，因此我想总结一下调试程序的方法，以后在碰到这种情况时希望可以少花一些时间。
保持清醒
无论编程还是调试的时候都应该确保自己是清醒的。在自己状态不好的时候编程只会给自己挖坑，为后面的工作埋下隐患。
预防/减少bug的出现
经常在各种地方看到一种观点：花在调试程序上的时间比花在写程序上的时间要多的多。我觉得这里的调试如果指的是tuning/traning/learning的话是可以接受的。如果理解为debugging的话，也会发生在很多人的身上，但是我们却应该避免并且有能力去减少这种情况的发生。我们与其花大量时间去寻找、修补bug，不如在动手之前花足够的时间去想清楚自己要写的代码。“三思而后行”，想清楚的标准大概是：
- 确定程序要完成的任务/目标； 我们为了实现程序的功能才写程序，而不是为了炫技、好奇、兴趣、冲动写程序，不要做南辕北辙的事情。
- 知道为了实现这些目标应该用什么算法/逻辑，并确保自己正确理解了这些算法/逻辑； 如果不清楚某个算法或者业务逻辑，那还是先补补课吧。自己都不懂的东西，就这么写下来敢保证自己写的一定是对的？别人做实验依赖你的结果，或者你有一个更大的项目依赖于这个不一定对的程序的输出，要是别人的实验结果出了问题或者你的项目出了点问题，你都不知道是你的程序出了错还是别人的程序或者你这个更大项目依赖的其他代码出了错。你以为节省了理解小范围代码的时间，结果却需要花时间去检查这个更大范围的代码哪里出了错。更糟糕的是，有时候我们都不能察觉程序出了错。比如我们写了一个极不均匀的随机数生成器，然后拿这个随机数生成器去做图布局的随机化或者做随机梯度下降这种东西，无论单看这个随机数生成器还是看图布局算法或着随机梯度下降算法的结果，我们都很难发现这个过程是有问题，因为我们无法一眼判断这个随机数生成器的结果是否合理，更难评判后面这两个算法的结果。测试也许能够发现这些问题。然而全面的测试往往需要生成测试集和比对测试结果，这显然又需要我们编写测试程序。可是由于我们没打算拥有理清代码逻辑、保证算法正确的良好习惯，因此我们的测试程序的代码也可能是有问题的，难道我们又要写测试程序的测试程序？这样想下去真是无穷无尽了。另外有的时候测试的执行也会花相当长的时间(测试样例多或者单个测试样例的执行需要花长时间)。
- 养成良好的编程习惯 感觉内容太多，放在另一篇里总结吧。
近期评论