10项调试基本规则

http://www.gipsysoft.com/articles/debug-rules/   文章来源   

第一次翻译东西，有很多bug，大家多原谅         

10项调试基本规则

这篇文章是在 David J. Agans 的撰写的《 调试 ： 9 条必备规则 可以 找到最 隐晦 的 软 件和硬件 问题 》的基础上完成的， David 根据自己的经验列举了 9 条调试规则，我希望每个人都能读到它，因为不仅它简短易读，而且有里面很多斗争故事会让你开心微笑。

我还认为这将是值得总结书的内容的对于那些懒得去读书的开发者，甚至是那些懒到连很短的文章都不愿读的开发者。

我增加了第十条（调试数据）规则， 不仅 它是我的个人经验，更是当数据混乱的时候很容易去浏览代码，很容易检查到那些容易被忽略的 bug 。

有争议的是很多规则可以相互结合使用，不过我认为这样结合是不值得的，因为它们现在是那样的简单明了，简直就是调试的标准答案。

调试数据

检查数据是否是你和系统需要的，当然这可能意味着你要写大量的代码来验证你的数据，不过可能只是一点小错误。考虑建立有能力检查输入数据的系统来把数据纯文本化。

深入了解系统

阅读系统操作手册，根据说明进行操作，根据样品代码检查你的代码，确保当系统需要 short 类型时你没有传送过去一个 long 类型，并且确定当想传送 long 类型或者 short 类型时，传送的正是你想要的结果。

再造错误

重新制造类似问题，很难复制的问题应该通过改动和挤压来实现它。

如果有些问题发生的频率很低，你可以根据你的良好判断能力和猜测哪个变量的改变可能增加它的频率性。

如果你的耳机出现了问题（有异样的声音）而你怀疑是某些线松动的原因，你可以扭动故障线的周围看是否增加的异样声音出现的频率，这样的方法同样也适用在软件中。

不要思考去观察

不要根据手中很少的消息而匆忙得出结论，逐行逐步的检查代码来消除未知的东西。

给你的软件增加调试日志功能，如果客户有问题的时候，你可以更好的获取相关信息。

使用任何你会使用的调试工具，从静态代码分析到动态单步调试都要尝试。

分而治之

缩小你的一次调试范围，减少 bug 能够隐藏的地方，尽量使用简单的测试数据，不要忽略任何发现的 bug 即使它和你正要处理的 bug 看似没有任何关系 ---- 因为一个 bug 可以以其他的表象为掩饰，记住：当你处理完另一个 bug 后要回头去处理本来打算处理的 bug 。

一次只改变一个事情

如果你打算处理一个 bug 并且尝试后 bug 已经解除就继续下去吧。如果没有解决 bug 问题，那必须问自己个问题：它有什么用途？然后删除它。

进行比较现在的系统和正常工作的系统，看发生了什么变化，比较成功运行和失败运行的运行日志。

不停的检查

当处理完一个棘手的 bug 时不管多小的日志信息都要保留，即使很小的细节也可能造成很大的影响，你最好不要判断某些东西在产生 bug 的过程中起多大作用。

在审查日志中寻找需要的模式。

先处理明显的

不要假设你的假设是正确的，怀疑任何东西。

它可能是个编译器 bug ，程序库 bug ，操作系统 bug ，甚至是调试器 bug ，测试工具 bug.

当你检查内存分配问题的时候要确信你分配了正确数量的存储空间，检查你是否进行了初始化。

向其他人寻求帮助

向同事或者朋友求助，常常只是解释一下问题就可以理清你的思路，使你认识到问题的所在。

向专家请教可能很快就能产生答案，或者在互联网上留下相关信息，等待一天看是否有人留下有帮助的信息。

如果你不处理它，它会一直存在

Bug 们不会自己处理自己，如果你不进行处理或当时 bug 没有解决，以后你会更难解决它了。

检查你是否真的通过你的处理方式修正了 bug ，处理了错误，然后在应用你的处理方式再一次处理其他错误。