程序员定位解决问题方法论

如何更快的解决问题？

我们在遇到bug的时候 如果每次遇到问题都是搜索 打断点调试 那我们有什么长进呢？

如果遇到那些搜索不到的 无法断点调试的问题呢？ 做人啊，要想得长远一点。

所以我们不如现在就培养一种思维，摈弃断点调试，靠猜，先把问题列出来，评估下排除这个问题需要多少时间，再着重的去做。

我们往往就会陷入一种直接动手去做，花很多时间去解决问题，这样固然解决了问题，还印象深刻了，但真正得到的收获却并不多，关键是很多时间被浪费了。

场景模拟

比如吧，我们看这么一个场景。

我用redis缓存了文章的数据，但为什么每次sql查询比redis获取还要快，redis出了什么毛病吗？

1.首先要把自己放的很低，为什么你这种问题自己遇到了，别人遇不到？redis出了问题？人家不会修吗？还恰好是你这个用的不熟的人找出来的？你把那些大佬放在哪里？

那么就可以提出问题了

1.redis有问题？ 概率0.01%，正好被我这个菜鸡找出问题了，我要去提bug上github。

2.redis配置写的不对？概率10%，之前用的好好的啊。

3.redis数据满了？ 概率5%，那为什么就我这次查出现了问题？

4.我插入的数据太大了？概率50%，我明明就写了那么点东西啊。

5.我调用的方法有问题吗？50++% ，但可以稍微看一下， 好久没用了，可能方法调错了。

草草的列出了这几个 。

那么就来看具体看一下，查的慢 ，数据太大了，可是我打印出来，就这么点数据啊，怎么会有问题，但是我一看可视化界面，他说数据量太大，还有\x00\x00\x00的乱码？

就很矛盾了，一个是数据量大，一个是打印出来好好的？ 夹杂的\x00\x00\x00是什么东西？

再回去看一下那个方法的调用。
如下所示

哦，果然是调用出了问题，第三个参数是过期时间，结果却是偏移量，导致数据中出现了很多为空的偏移量。

下面我们就来说说程序员遇到类似的问题不同的应对方案。

第一层境界

一腔热血，一想到有什么问题就去做，憨憨的断点调试，属于第一重境界，就是初级程序员的水平，大佬绝不会用这一招，急着动手去做，是很多人，包括我在内的人的通病，可能这样会让你印象深刻，但是会浪费大量的时间，还不一定能解决bug。

第二层境界

出现问题的现象是什么，最有可能出现的概率是什么，将这些概率列出来，再以最高概率依次排列，再去查，不行就排除掉，这是第二层，就像上面列出的那些可能一样，根据自己的感觉评估，当你排除了一切可能，剩下的就算再不真实，那都是真相，当然你得确保出现的问题一定在你提出的可能性当中，极端情况可以忽略。

第三层境界

将每个问题出现的概率，要排除的时间也列出来，如下所示

1.redis有问题。概率0.01% 正好被我这个菜鸡找出问题了 我要去提bug 翻源码？排除预估用时，未知！！！！ 几个小时 还不一定能找出原因。

2.redis配置写的不对？概率10% 之前用的好好的啊 ，排除预估用时：10分钟。

redis数据满了？ 概率5% 那为什么就我这次查出现了问题？ 排除预估用时：1分钟。

我插入的数据太大了？概率50% 我明明就写了那么点东西啊 排除预估用时：5分钟。

我调用的方法有问题吗？概率50++% 但可以稍微看一下 好久没用了 排除预估用时：1分钟。

综上 ，概率大，用时低的优先，先去查方法调用，再去看插入数据的原因，往上依次去排除，比打断点花的时间少了很多，因为你打断点有时也不一定你能知道原因，反而浪费大量时间。

第四层境界

有人问，还有没有第四层？

那我想，就是第三层的方法+断点调试(二分调试)+不定时的提醒。

我们在排除某方面的问题时，可能会用到断点调试，有可能是某个方法出了问题，但一个方法又包含了大量代码，几千行，你难道一个个看下去？

我们确定某个问题，再给这个问题定一个代码的范围，如果实在定不了，那么就可以尝试方法的一半处打断点，再二分缩小范围，这个也只适用于特定的情况，有时候二分并不好用。

我们对预估的错误定一个时间，比如2小时之内搞定，那么可以在15分钟，半小时，一个小时，分别设置一次提醒，有没有走死胡同？有没有在某个问题上卡太久的时间？出去散散步，清空一下思维，再回来解决。

暂且只想到了这几层，如果有更好方法，欢迎留言，我会在后面补充第五层境界。

纯善或者纯恶的人是不存在的，就像一张平滑的纸一样。人都是拥有着很多面的，就像一张对折后的纸，才能稳稳的站立起来。