查找bug的几个方法

2022年已经过去了，新的一年到来了，而我也又老了一岁。过去的一年又带了几个小弟，总有一些经验要给他们分享，与其小圈子说不如发个文，让CSDN上的小朋友们也借鉴借鉴吧。

bug查找的基本原则

作为一个程序员，自己写的程序不出bug那是不可能的，所以如何查找bug就是个重要的事情，如果你统计一下自己的代码填充速度，其实最耗时的未必是你写一段代码，最耗时的往往是调试程序的结果不是你的期望，究其原因，就是最耗时的往往是程序里面写出来的隐藏bug。

先别着急，我们在态度上先要明白，人无完人，程序也没有最完美的程序，所以我们需要耐着性子坐下来，查找bug，查找它们产生的原因，然后修改之。

这时候，如果盲目地去找bug未必能提高你的代码编写效率，而掌握下面几个原则则是解决这一问题的基础：

原则一：我的程序或许未必是分模块的，但是在我心里，它是分模块的。良好的编码习惯当然是程序要分模块、分文件、分类编写，这样有利于功能集中、便于读写，但是我们免不了碰到小弟或者初学者写的东西需要修改，有些大神为了隐藏自己的工作成果，有时候也会做一些隐秘动作，让代码的可读性降低，但是无论怎么样，这东西到了你手上来修改，你如果要处理里面的东西，不管它有没有结构，你都要在心里将他模块化，梳理出模块之间的调用关系，才能为后面的修改奠定基础。

我不赞成一上来就先动手的，如果你没有首先建立模块原则，那么就无法套用黑盒原则，这样上手就改往往会越改越乱。

原则二：程序就是一道道水流，线程的进出点是查找问题的关键。

程序是由一条或数条进程组成的，进程中又可以分出很多线程，查找bug出处的重点在于定位bug而不是修改它，因为我们查找bug的时间往往比修改它要多得多。那么看看水流吧，在数条纵横交错的水道之中要定位问题，最快的办法就是在水道的出入口查看异常，因为你不可能飞到天上去。

同样，大多数情况下你不可能把每一个交互过程、程序分支都画成图，然后站在图上来看。

这时候，我们在调试过程中其实就是通过程序模块的输入输出来确定这个水流是不是正常的。

原则三：程序的健壮性永远是少出bug的保证。好的习惯会让你事半功倍。

什么是代码质量？程序的健壮性永远是代码质量中重要的一环，为什么有的人写的代码似乎很难出错，而有的人写的代码稍有状况就宕机？这就是代码的健壮性。

就比如，我在判断一个临时字符串变量的时候永远会在分支前判断一下字符串是否为空，就是保证代码健壮性的一个习惯。

一些方法

记住上面的三个原则，那么不论在什么情况下，不论是什么语言编写的代码，你至少可以少花一些时间在代码调试上。下面就一些实际操作中常用的方法探讨一下，帮助你尽快完成工作。

方法一：模块调试。

通常我们最初的查找问题的办法都是从功能模块级开始的，因为从这里向上，通常是服务块，服务块的错误一般都是可见的错误结果，也就是外行门通常批评我们的直接证据，从模块向下，则基本上都是类文件，从这里我们很容易找到一个功能的入口和出口，方便开始查找bug的工作。

例如对于java spring，从controller可以找到每个功能块的入口方法，在controller中添加个main方法，就可以调用service来定位错误。

所以，从模块入手是我们最最常用debug查找方法。

方法二：前后台分离，确定问题出在前台还是后台。

其实前后台分离的软件架构方式好处之一，便是定位错误更便捷了。我在调试问题的时候很多情况下都是用postman模拟一个请求，然后在Java里面跟踪调试来确定错误的。

如果你是一个后台开发者，或者你是一个前台开发者，当你这么做的时候，你会发现你更容易把你的责任推出去了，因为你的对端可能出错了。当然，这么做的前提是你能确定错误实在后台或者前台。

方法三：分段输出。

通常，一个成熟的程序员在写代码的时候，会在不同的位置用log日志输出一些看起来无关紧要的东西。其实这是一种习惯，有的bug未必会在编码的时候出现，他有可能会在程序运行过程中突然出现，而对于这些不确定的危险，平常又很难抓住，所以通过日志在一些可能会出现危险的地方预先设置一些记录，是增强程序健壮性的通用办法。

这就跟你每天出门前会给家人说“我走啦”的道理是一样的，如果今天你出去了晚上却没有回来，那你的家人会第一时间打电话给你：“你怎么还没有回来？是不是出什么问题了？”是一个道理。

方法四：善用调试工具

浏览器是一个很好的调试工具。

说这一点是因为我看到一些新的程序员恨不善于利用它。

现在的浏览器无论是谷歌、火狐还是腾讯浏览器，他们都提供了开发人员组件，按一下F12就能调出来，而其中就具备了“调试模式”，在它里面可以对js代码打断点，帮助我们定位页面中的错误。

有这么好的工具，为什么不用呢？

当然，如果你自己能够分析出来错误，另当别论。

又例如我上面说的postman，他甚至可以将历史请求记录下来，方便我们后期跟踪问题，为什么不用呢？

方法五：控制台打印。

这种方法很父老，但是也很实用。有时候，我甚至用它来生成一些模拟数据，看看线程处理中对于一些公共变量的处理是否出现了问题。

方法六：在一些可能会出现问题的地方加上try……catch。

除了java、c#，js里面也是可以加上try……catch的，将e用console（）函数打印出来，我们可以看到绝大多数的前端错误。

方法七：函数测试。

其实更多的办法或许有更好的结果。有时候。我们面对一大堆程序很难分出模块，与其在程序里面找问题不如将其中的一些关键代码拷贝出来，形成新的单独文件，这样排除干扰之后能更快地定位出来问题。

方法八：经验判断

如果你实在已经找的木了，也没找到问题所在，不如求助一下吧，在网上发文是一种方式，而问一下老程序员也是不可或缺的好办法。而且，作为程序员一天对着电脑，本身就极少与人沟通，语言能力会退化，为什么不乘此机会说说话，跟同事们搞搞关系呢？

好了，本文到此就结束了，谢谢大家观赏。