那一夜，你伤害了我……

前两天，小编用程序员们开发的系统搞事情。

然后，发现了bug。

然后程序员们跟这个bug搏斗了许久，终于好了。

就在刚才，对，小编又不小心又发现了bug。

……不说了程序员要打死我了。

那么，遇到bug的时候，都有什么办法解决呢？

小编整理了一些隐藏的大神的回答。

@匿名

@YY

1. 注重逻辑性 

首先，你要定位 bug，不要做没有证据的结论。

如果你有猜测，就去证实或者否定它。

比如某次，同事代码返回的数据有问题，认为是缓存用的 Redis 有问题，返回了错误的数据。

然而没人去对此猜测进行求证……

我去确认了一下，Redis 收到了请求，并且响应正常。

真相就是，代码里有个 } 的位置放错了，因为它刚好在一屏之后的位置，所以没有人发现……

2. 基本的方法论

比如二分法。

比如最小化测试用例。

如果你要提问，不管是向搜索引擎还是向人，你都需要提出正确的问题。

3. 知识面

你写 Web 后端的话，普通的 HTTP 得懂，浏览器的开发者工具得会用。

简单的 JavaScript 也有会点儿。

简单地说就是，你要精于你自己主攻的部分，然后要熟悉你的上下游。

再比如如果你使用 CPython 的话，你要准备一份 CPython 的源码，并且要能够流畅地阅读 C 代码。

4. 工具

工欲善其事，必先利其器。

一大堆调试用的工具，你至少得知道它们能干什么，需要的时候能用。

比如 strace、lsof、gdb、git bisect，还有 sysdig、systemtap、perf 等。

当然还有一堆不是专门为调试而设计的通用工具，比如 the silver searcher 或者 ripgrep。

一个快速的全文搜索工具能帮你在最短时间内找到相关的代码或者日志。

你不必成为正则表达式大师，但是简单的一定要会。不然面对上千个匹配结果你要怎么办呢？

@jim jin

先试试以下步骤：

1. 换个环境试试

2. 换个用户试试

3. 换个操作方法试试

4. 换一下数据试试

5. 换个浏览器试试

6. 换个版本试试

7.换个人操作试试

下面列出一些常见的疑难BUG类型以及每种BUG的诊断方法：

1. 输出结果与预期不符

这种BUG一般都是由于代码逻辑错误造成的。

如果能在开发环境重现，最好解决方法就是单步调试，设定每一步代码的预期结果。

然后跟踪判断实际结果是否与预期结果一致。

如果在开发环境无法重现，无法单步调试的，可以采用添加输出日志的方式判断哪一步的问题。

2. 系统异常报错

这种情况下需要提取日志，找出错误堆栈信息。

这时候最重要的事情是要把堆栈信息看懂、看完整。

往往堆栈信息是一个套一个输出的。

比如Java里面表象上看是一个NullPointer Exception，但是如果你看到底，就会告诉你到底是什么错误引发了这个NullPointer。

3. 系统Crash

这个问题常见的原因是负载过高、并发过高、或者配置错误。

最常见的就是内存溢出。

这时候要首先排除配置错误的原因，主要靠查看Crash Log来分析原因。

如果Crash Log没有有用的信息，就得排查硬件、内存、网络等方面的设置，看是否有配置错误的地方。

再找不到就在测试环境用开发模式进行压测和调试。

4. 系统响应缓慢

这种问题一般是存在资源竞争或者系统资源不足的情况。

最后，如果某个地方出现BUG实在找不出什么原因，那就上我们的绝招——“小黄鸭调试方法”吧。

去买一只小黄鸭，就下面这样的，注意个头不要太大。

把小黄鸭放到电脑屏幕上方，就下面这样的，最好面对着你。

打开你出问题的那段代码，面对小黄鸭。用手指着代码。一行一行的给它解释一下这行代码是干什么的，为什么这么写。

现在你知道问题所在了吗？

各位程序员，小编只能帮你们到这啦！

祝大家天天开心，永远没bug~