为什么大佬debug五分钟，你却要两小时

今天我们来聊聊debug，bug这东西几乎是所有程序员都绕不过去的。

先来聊个冷知识，大家知道为什么程序里的问题要叫做bug吗？

这和当初计算机的结构有关，在计算机刚刚诞生之初，当中的计算单元还是晶体管。使得整个计算机的体积非常庞大，比如最早的计算机ENIAC体积巨大，足足能占满整个房间。

在1947年时，有一次科研人员设置好了继电器和程序之后，计算机却突然宕机了。于是人们对整台机器进行了仔细检查，最后发现计算机内部一组继电器的触点之间有一只飞蛾，由于被发光吸引飞入了其中，导致阻断了电路。在事后的事故汇报当中，人们把这一次的事故记录成了“bug”，这个单词的原意就是虫子。后来这个叫法就被沿用了下来，凡是计算机系统中出现的问题，都被统称为了bug。

对于萌新而言，可能最不愿意遇见的就是debug。因为往往debug的过程非常漫长，经常绞尽脑汁也不知道问题出在哪里。久而久之就对此充满了畏惧，一看到红色的error出现，就头大如斗，心烦意乱，情绪变得非常暴躁。

再反观团队里的资深员工，或者是实验室的师兄们，他们遇见bug时却淡定自若。云淡风轻，一些看起来非常棘手的问题，随随便便就解决了。于是萌新们常常扪心自问，为什么他们这么熟练呢？自己什么时候才能像他们这样？

然而每一个大神都是从萌新开始的，某种程度上来说debug也是一种技能。既然是一种技能，那么就是有迹可循也是可以通过练习提升的。接下来就给大家分享几点小技巧，帮助大家遇到bug时能应对得更加顺利。

稳定心态

遇到bug时，第一要义，也是最重要的就是稳定心态。

绝大多数人在看到bug的那一刹那就会心烦意乱，非常烦躁，甚至连报错日志都不能看完。然后匆匆找大佬来解决，结果大佬来了之后一看报错，是一个很sb的问题，场面一度静止。

所以遇到bug时，最先要做的就是冷静，稳定住自己的情绪，克制住心里的烦躁。只有心情平静，你才能仔细地阅读报错日志，分析问题可能出现的原因。

另外常见的容易破大防的情况就是一些奇怪的问题，匪夷所思，违反逻辑的问题。这种奇怪的问题对于心态的破坏性更大，很容易让人破防，让人觉得见鬼了，然后去求助大佬。但根据老梁的经验，没有什么匪夷所思的情况，也没有离奇的问题，如果有，那么一定是你忽略了什么，一定是哪里搞错了，而且有可能就是最基本的地方弄错了。最后我总结出来一条定律：看起来奇怪的问题，往往有一个sb的原因。

这个时候千万要冷静，仔细梳理情况，仔细核对每一个细节。

屏幕输出和二分法

很多萌新喜欢使用单步跟踪来debug，所谓单步跟踪就是让我们可以打断点一行一行地执行代码，并且能够检查当前所有变量的取值。

单步跟踪虽然很好用，但我不太推荐萌新使用。原因也很简单，因为很容易养成依赖，最好的是通过阅读代码核对逻辑就发现问题，这样最能锻炼阅读代码和分析问题的能力。如果你以后要分析一个服务器上的问题，只有报错日志而没办法单步跟踪时，你怎么办？你总不能根老板说没有单步跟踪我就搞不了吧。

所以阅读代码逻辑的能力非常重要，不要等万不得已的时候才锻炼。

我个人比较常用的是屏幕输出的办法，把一些中间变量输出出来来印证和检查。这样哪里有问题，只要跑一下代码就知道了。并且这种办法还可以结合二分法一起用，很快就能找到出问题的代码片段。之后再仔细阅读逻辑排查问题即可。

不过要特别注意并发场景，如果是多个线程并发执行，那么线程之间的执行顺序是不能保证的。这也会导致最后的输出结果乱序，因此要特别当心。

磨刀不误砍柴工

最后一点是磨刀不误砍柴工，很多时候我们不能做一个问题解决机器，只是机械地解决问题。我们也要主动学习来避免或者有能力从原理上分析解决一系列问题。

比如我以前做Java的时候，经常遇到maven冲突报错的问题。一开始每次我都是上网搜如何排查冲突，怎么解决冲突。有的时候多个冲突绕在一起，或者是叠加版本问题就非常头大。网上搜来搜去也找不到一样的情况，只能根据一些能对上的信息去猜。试着去操作一下结果又遇到了新的问题，新旧问题叠加没完没了，完全不知道怎么办。类似的情况经常反复查实现，最后逼得没办法只能找人求助。

求助得多了，我感觉大佬看我的眼神都不对了。最后实在是惹毛了，一咬牙花了一下午的时间系统性地学习了一下maven的运作原理以及使用方法。看起来花的时间多了，但后面再遇到问题就不像之前那样抓瞎了，逐渐开始有眉目了。能通过分析日志以及配置，推断问题出现的原因，找到原因之后也能试着解决问题了。

随着尝试次数的增加，整个过程变得越来越熟练。最后我也能像大佬一样，看一眼报错日志就知道怎么解决了。

所以有的时候遇到问题也是一个很好的学习机会。相比于单纯地解决问题，如果你能多挖一层，多思考，多学习，从根本上理解了问题出现的原因。那么相信不仅是debug，你的总体技术能力也一定可以飞快成长。