老程序员解 bug 有哪些通用套路？ 第1页

其实没什么特别的，有一点比较特别的可能是在做任何改动之前，我会先想清楚两件事情：

1、改这个可能得到哪些结果？

2、这些结果说明什么问题？

然后，我会把代码改回去，除非结果证明这个改动是有益的。

其实这显然是常识，而大部分的程序员非常的奇怪，他们总是这样思考问题：

我为什么不改改这里呢？

你为什么不去问问神奇的海螺呢？

所以，找出Bug的方法步骤很简单：

1、找出最有可能出现问题的模块或者代码。

2、设计一个实验证明这个模块有问题或者没问题。

3、进行这个实验并记录结果。

4、根据实验结果进一步排查问题。

而很多程序员都有一种蜜汁自信，他们认为2-4步骤是对他丰富经验和敏锐直觉的侮辱，他们总是能直接发现问题的所在并且直接进行修复，然后寄希望于奇迹发生。

所以，你为什么不去买注彩票呢？

==================================================

一个常见的场景是这样的：

这边有一个很麻烦的Bug请求援助。

好，那么目前的情况是怎样的？

首先测试提出了这样一个Bug，所以我怀疑是A模块的问题，所以我把A模块的这个改了一下。

嗯，改了之后呢？

改了之后问题好像有所缓解，又出现了B的现象，所以我又把C模块改了一下。

等一下，你在改A模块的时候，有没有考虑过出现B的现象？

我怎么可能提前知道会出现什么现象？

OK，你不知道，这没什么关系。那么你在修改A模块的时候，有没有期望这个改动会带来什么结果？

期望结果就是问题解决啊，，，，，你怎么把问题搞这么复杂，你看，现在问题已经解决的差不多了，我们只要把C改一下，嗯……

May God bless you……

大概就是这样……