改bug

步骤1：复现

都说如果一个bug可以每次复现了，那里它的解决也不远了。这里其实有一个隐藏的道理——就是如果你每次都能把bug复现，就说明你已经知道bug的确切产生条件了，而条件就对应了软件里的分支，所以你知道bug的产生条件，你就可以知道大概可以在哪里打断点了，产生bug的数据流大概是怎么样的。

步骤2：调试

能调试就是幸福的（后面会讲到不能调试的bug）。每个bug都对应着一个现象，每个现象在软件里其实就对应了一个变量的赋值，我们要解决一个bug，一般首先在软件里找到问题发生时场景所对应的分支，看在此分支下，现象所对应的变量是不是赋了一个错误的值。如果代码里问题所发生时场景下，变量没赋值错误，就转头找变量赋了对应错误值的地方，往往变量赋了对应错误值的地方还有好几个，但是第一步中的复现在这里就可以帮我们排除大部分可能性。这种情况下，我们可以建立如下模型：

本来是应该在A条件下，X变量赋值为a（正确值）；

结果却是在B条件下，X变量赋值为b（错误值）；

其实一般情况下，A条件和B条件往往还有个母条件C，这时候找到C条件走到A条件和C走到B条件的差异就至关重要。假设C+D=A，C+E=B，就说明我们本期望在bug发生场景下D条件成立的，实际上却是E条件成立。而D条件和E条件的不同往往只是一个细节处的变量没有赋值对。我们再跟踪此变量，递归以上步骤，就可以一步步接近事情的真相，而达到bug的解决。

依我看来，bug分为两类：1. 可以调试的bug，看调用；2. 不能调试但是能printf的bug，二分查找法； 3. 时间性的bug，看sleep，看阻塞，看大循环；4. 概率性的bug，控制单一变量法复现，拷机打印log，打断点看调用栈。5. 库代码的bug，了解库原理，反馈。

1. 好解的bug

什么属于好解的bug？在我看来属于业务逻辑错误，可以调试的bug，都属于好解的bug。当然好解的bug也并不一定好解，但是如果确定只是业务逻辑错误，而且可以调试，至少有迹可循。