解bug有哪些通用通道

转载自https://www.zhihu.com/question/61826619/answer/207406782?utm_source=qq&utm_medium=social

1 代码本身没有问题，但每次执行到那一行就是报错，最后跟踪出来是内存溢出的问题；

2 代码本身没有问题，但因为对API不熟悉，在使用的逻辑上有问题，导致了莫名其妙的现象，比如Android的AsyncTask；

3 测试定义为随机问题，只能通过走读日志和测试描述的步骤来推理解决；

4 因为打印导致耗时严重影响性能的问题；

5 单步调试无法定位到问题的原因（多数是因为多线程的原因），只能通过打印解决；

6 因为编码上的疏忽大意，跟踪很久结果发现是非常低级的错误；

7 正常使用没问题，但频繁调用某个方法导致代码重入的问题；

8 没有足够的日志，只能通过用户描述的现象和代码推理来分析程序的逻辑是否有问题；

9 其他同事找我协助解决问题，对他们的代码完全不熟悉，只能通过分析和排除法来解决；

因为遇到的多数问题不管解决过程多曲折，基本都能得到解决；再加上丰富的写bug和解bug经验，自然而然形成了一套属于自己的解决问题的套路，正好昨天晚上给公司大学生分享这方面的内容，将我自己的套路总结了下：

一 解决问题的流程：

了解问题→定位问题→分析问题→解决问题→验证问题

在解决问题之前一定要弄清楚具体的问题是什么，看到过太多纠结了很久但发现自己所解决的问题并不是测试描述的问题的情况了；

解决bug最耗时的地方在于定位问题和分析问题，这个可以借助“二”中介绍的几种方法。

这套流程不仅仅适用于解bug，同样适用于解决工作和生活中的各种问题。

二 解决问题的方法（排名分先后）：

1 借助搜索引擎：

遇到有明显的异常信息，且自己并不熟悉为什么异常时，最高效的解决方法是借助搜索引擎，这里的搜索引擎一定是谷歌，不是百度；借助搜索引擎能解决工作中的大部分bug，你要相信，全世界这么多开发人员，你遇到过的大多数问题其他人也遇到过；

2 打印调试法：

这是最笨但最有效的办法，人会说谎、断点调试可能会说谎，但日志一定不会说谎；

3 二分排除法：

当你遇到随机问题、帮助他人解bug或者遇到自己不熟悉的代码时，通过屏蔽一部分代码，运行观察问题仍然存在，如果存在则进一步分析屏蔽一部分代码，直到定位到有问题的具体位置为止，这种方法能解决工作中的很大一部分疑难杂症；

4 小黄鸭调试法：

当你向某个对象陈述你的思路时，往往会有意想不到的结果，哪怕对方并不是一个生物；断点调试法：受限于效率不高以及在多线程环境下断点调试并不灵，有必要时才考虑用这种方法；通常可以使用打印调试法来代替；

5 线上求助：

包括论坛提问、RTX和微信群提问等；不到万不得已不要用这种办法，在有限的圈子里面，你遇到的一个具体技术问题很有可能其他人并没有遇到过，多数时候问了也是白问，但有时候也可能是一种有效的方法。

很多时候我在想一个合格的开发人员，工作两年和工作一年有什么区别；工作多年与工作一两年又有何区别。得到的结论无非就两个：

工作越久，应该越靠谱，不然你和刚入这行的小伙伴没有任何区别；有一套属于自己的解决问题的方法，遇到任何问题都能够通过自己的套路去解决。