BUG调试技巧

写代码就难免有BUG，很多时候，BUG令人无从下手，似乎很鬼畜，似乎不符合语言、编译器甚至是计算机的运行机理。但是往往最后我们发现，越是难以置信的BUG来源于更低级的错误与失误。

（一）、更多时候，调BUG考验我们的并非对于编程技术、对运行机理的理解或者别的技术相关的，而是我们的心态。

（二）、怀疑该怀疑的，坚信该坚信的。这需要我们做一个筛选，在所有的用到的代码、库和工具中，有一些需要我们坚信其是不可能出现错误或者BUG的，除非是我们忽略了它们定义的规则。而通常，我们至少要信任自己的编译器。一旦确定了该被信任的工具，那么在单步调试过所有代码之前都不要在怀疑。这并不永远是对的，但是这绝大多是时候是正确的。当我们过早的怀疑这些本该信任而又无法查看源码乃至没有过多说明资料的对象时，我们会发现我们的BUG永远都不可能被调试出来了。我们推选出的该被怀疑的代码里面，我们应当遵从这样的怀疑等级顺序：自己写的代码>同事写的代码>免费的第三方库>收费的商业性第三方库。

（三）、大胆假设，细心验证。这其实是一个很难的事情，至少对我本人而言，这和性格有关，但是我们应当经常提醒自己去做到。越是难以置信的BUG往往来源于更低级的更难以引起注意的一些小的细节上的失误，比如>、<错写成<=、>=或者相反？索引从0开始还是从1开始？等等诸如此类。在该被怀疑的代码里面，放心大胆的去怀疑吧！然后仔细的调试、验证你的怀疑。

（四）、更多的依赖官方资料。曾经有一位老师曾经告诉我：“如果这些设计者出具的资料都不可信，那么世界上还有可信的资料吗？”在你所能找到的所有的资料中，配套的官方文档（如果有的话）是最值得信任的，它不带有任何与编辑者知识、认知、经历等任何相关的产物，只有最最直白只为说明问题的文字。

（五）、合理断点和Log。这是调试BUG最常用的方式了，但是似乎很难说清需要在什么地方打Log或者断点，也就是怎样才算合理。一般而言我认为Log用来确定问题出现的位置，因为运行时不需要回到源码就可以查看想看到的关键值的状态，而断点则用来确定这些问题出现的原因,因为当断点触发，代码块中所有值得状态都能看到，整个执行过程能够推演回去，而且调用堆栈（Call Stack）能够回退到更早的代码处，并且还原当时的值的状态。