调试九法总结

2017-12-17  本文已影响32人  闫正阳

调试九法总结

最近两周，阅读完了《调试九法》，又认真的思考"调试"究竟是什么东西？
对于一个程序员来讲，调试就是Debug，消除代码中的Bug。对于硬件工程师来讲，调试就是找出硬件出错的原因。
然而抽象来讲，调试其实就是找出问题的原因，并研究如何去解决一个问题。
《调试九法》使用了作者本人经历过的多种案例，向我们一一说明，如何去解决一个问题。

规则阐述

既然是《调试九法》，当然是介绍九种方法去解决一个问题。
书中提到了九个规则，依照作者的说明，按照这些规则去解决问题，往往能很快就得到解决方法。

规则一 理解系统

这个规则很容易理解，理解系统的意思就是说，当我们遇到问题时，首先先判断自己使用一个工具的方式是不是正确，是不是符合预期。
在一些简单的开发过程中，容易出现这样的问题————一个很简单的代码，然而最后的结果不符合预期，最后却发现只是因为函数的调用方式不正确，或者参数类型不对。
在遇到问题的时候首先应该想到是我的使用方式是不是有问题，然后去阅读一下相关的说明文档，也许就能找到答案。

规则二 制造失败

判断Bug一般会有一个指标叫复现率，如果一个Bug的复现几率是100%，那么这个Bug就很容易被定位，进而很容易观察以及调试。
然而如果一个Bug很难复现，或者是周期性的，那么就要想办法让他更容易复现。

同时作者还提到一点，不要模拟失败。有可能一个模拟的环境并不能等价于Bug出现的环境，这样就很难定位到Bug，要通过其他工具在现场观察Bug。

规则三 不要想 而要看

这条规则比较简单，我们在进行调试的时候，多进行观察，而不是想当然的去猜。当使用了规则二复现了Bug之后，就可以利用手头的工具去认真观察这个Bug。比如打印Log或者使用GDB。
单纯一味的去猜想问题的原因并进行修改，很有可能精疲力尽但仍然没有任何的头绪。
这一条中提到了插装的思路，即使用各种外部组件，在不影响程序内部运行的情况下，查看程序内部的运行状况。

规则四 分而治之

这条规则有点像二分查找算法。
如果一个问题的可疑区域很广泛，那么就很难被调试，通过使用其他的方法去逐步缩小问题的可疑区间，会节省很多时间。
如果一个问题有很多个分支，就从分支的根节点开始逐一确认问题的路线，逐步定位到这个"树"的叶子节点。

规则五 一次只改一个地方

这条规则有点像做对照实验的一条原则，对照条件要只有一条，否则无法确定是哪个条件改变导致实验结果不同的。
我们在调试时要遵照这个规则，即如果怀疑两段代码都有问题，则不要同时修改两个地方，而是逐一去修改，逐一去判断这段代码对于最终结果的影响。这次的修改一定要对正常的结果去做对比。

规则六 保持审计跟踪

在进行调试时，如果一个操作比较复杂，则一定要通过某种措施去记录这次修改的结果，很有可能当经历了复杂的修改之后，就会忘记自己的操作。在这里代码版本控制工具能为我们提供一个方便的功能，当有新的功能上线之后，如果出现问题，就很容易能回滚到上一个版本，并检查新提交的代码有没有问题。

这里作者提到过另一个问题，也就是如果让一个不熟悉系统的人去使用一个工具，那么当他遇到问题的时候，尽可能的使用详细的语言去描述如何使用这个工具。然后作为系统的开发者，就更容易方便的去定位问题的原因。

规则七 检查插头

在添加了一个组件之后，一定要在引入的代码块添加捕捉异常的逻辑。
对于一个复杂组件而言，是一个黑箱，无法研究具体的内部逻辑，因此很容易出现意料之外的输出，这个时候最简单的方法就是针对这个组件做一个封装，考虑到所有的异常输出，并进行处理。

规则八 获得全新观点

这一点其实是劝解我们要多虚心的向他人求助，很多问题在别人的经历来看，或许是他尝试了无数次之后才得到一个好的解决方案。当问题较为复杂的时候，一个人硬着头皮去干有可能会浪费太多的精力。站在巨人的肩膀上才能看的更高。

在求助他人的时候，一定要客观的陈述事实，不要想当然的带入自己的理念，否则可能会带偏别人。比如看病，细说自己的症状，而不是说：我可能感冒了。

如果你不修复bug，它将依然存在

这最后一条其实是劝解我们要尽可能的去处理Bug。
首先确认Bug是不是真的解决了：

可能有许多的Bug很容易随着时间的流逝不再出现，然而作为Bug的制造者而言，这个思维，这个想法会一直保留在大脑里，一旦下一次遇到这个问题，就有可能在另外一个系统里复现，因此重要的是纠正自己的错误的想法，找到解决问题的办法。

整体总结

《调试九法》的确是一本好书，讲述的思维从抽象的角度可以延伸到任何一个问题的解决思路，我还需要认真领悟，并尝试使用这九个原则去解决任何一个问题。

上一篇下一篇

猜你喜欢

热点阅读