bug 排查能力突飞猛进，我的一点小感悟

大家好，我是帅地。

最近在星球里有球友问了我一个关于提高自己查找 bug 能力的问题。

关于如何提升查找 bug 能力的问题，其实帅地也没有去总结出明确的方法论，但学了五年的编程，倒是有点小感悟。

我记得我刚开始学 C 语言的时候，明明是跟着书上的代码写的，但还是得不到预期结果，几十行的代码，我居然找不出 bug 在哪里，通过大半小时的排查，我发现是 if(条件) 那里多了一个分号，例如

if(条件);
{
  doSomething();
}

后来也是在一个很简单的代码里，特么我也是不知道啥错误，莫名其妙，也是搞了好久，最后才发现是在 for 循环里把「分号」写成了「逗号」。

不得不说，这些简单的错误，有时候贼难排查，因为这些错误不会报错，程序可以正常运行，当然，有时候也会遇到很多程序在运行中莫名结束的，例如学到指针那里就遇到运行中报错但控制台没有提示的 bug。

总之，刚开始学编程那会，有很多莫名的 bug，并且每次都排查好久，不过后来我基本都知道套路了，可能是熟悉了，每次有 bug，可以很快反应出来大致是哪些出问题，每次有人问我这代码哪里有 bug，我都可以很快找出来。

之所以能够快速找出，并不是我有多聪明，而且我经历过，查的多，有经验了。

后来，我做了 JavaWeb 这些项目，跟着视频做的，也总是遇到错误，而且不想以前几十上百行代码，这些项目上千行代码，而且各种依赖包，我记得我刚开始做的一个 SSM 项目，从 GitHub 拉下来的，师兄让我用 IDEA 去运行起来。

我很害怕，因为我对 ssm 项目不熟悉，这要怎么运行起来？没办法，我跟着文档弄，结果可想而知，我遇到了很多错误，特么我对 IDEA 也不熟悉啊，记得当时有一个 bug 我排查了三天三夜，那三天都没有睡好，就是 maven 打包的时候总是出现错误，当时我对 maven 也很不熟悉。

这个时候的错误，不像当时学习 C 语言那样，看代码逻辑就能找出来，而是涉及很多模块，很多依赖，这些依赖包的水又很深，基本不是说看看代码就能看出来的。

在对这些技术都不熟悉的情况下，我花了好几天，百度了好几天，终于把项目运行起来了，莫名激动，尽管花了好几天。

如果你问我在这个过程学到了什么知识，我会告诉你，我也不知道具体自己学到了什么知识，但我就是感觉自己查找 bug 的能力提高了很多，反正就是可以神经反应，大致知道从哪里排查，反正日后遇到这种问题莫名自信。

后来我工作了，以前自己做项目，都是在本地运行，自己也没有打印什么日志，或者说日志都是打印到控制台的，反正就是很不规范。

但是在大公司就不一样了，有相对完善的日志系统，而且有错误也不会打印到控制台上，因为都是在服务器上运行代码的，你得去查找对应的日志，有时候连日志在哪里，都不知道，，，

在以前，依赖包往往是你自己搞的，但在公司，整体架构是别人搭建好的了，依赖包也是有版本管理，别人搞好的了，所以遇到 bug，真的得看日志，跟着日志来，之后再去细查。

刚开始我还挺不习惯的，加上公司的网络环境莫名其妙，而且对 linux 那些 find，grep 等命令不是很熟悉，，，反正就是查找 bug 相对较慢。

后来我在公司接手了一个 D 监控的东西，是个老系统，问题贼多，经常有工单（就是用户的求助或者投诉啥的），然后我必须根据这些工单给用户一个明确的答复，注意，必须是明确，不能是「应该」，「大概」，毕竟客户是上帝。

那会一天好几个工单，我那段时间真的炸了，而且经常需要上线上的服务器排查问题，真的是各种莫名的 bug 都有。

bug 排查多了，有种自己身经百战的感觉，一点也不畏惧 bug，一遇到问题，脑子就会转起来，很快就猜测出各种可能性，然后排查，记得有次我导师问我：你这个是怎么想到的（突然有种得意的感觉）。

其实说了这么多，我是想说，对于查找 bug，我也没有明确的方法论，因为 bug 真的各种莫名其妙，但当你发现时，也确实并非莫名其妙，往往是因为自己不细心或者理解不到位导致的。

我觉得我查找 bug 的能力还行，这并不是因为我掌握了多少方法论或者多聪明，而是我排查多了，每排查一次，最后找出 bug 所在，这一次成功的查找经历，就会成为我的经验，每次遇到 bug，我就会去扫描各种可能，或者脑子就直接定位了。

所以我觉得，多多实践，是提升查找 bug 能力的一种有效方式。

如果你查找 bug 能力太欠缺，往往是实践的不够多，接下来可以多多脚踏实地，多查查 bug，可能就莫名起来提升上去了，最后也会形成属于你自己的方法论。

最后小破号求关注，每一篇文章都很认真