前方预警： 没有技术，纯吐槽。 吐槽目的： 暴露自己解决问题的思路， 收集更多不同的思路， 更新完善自己的方案！ PS：我这CSDN博客，活生生被我整成了“吐槽”大杂烩！ 本宝最近重悟英语学习论，大有新收获。 有木有也学英语的“吐槽”大军，咱们交流交流！
最近A， 耗费了2个多小时， 才解决一个bug。 不是说耗费2个多小时解决一个bug就是很low， 有些逻辑比较复杂的，有些历史渊源的， 说实在的，花上1天调通也是可以理解的。 为什么我会把这个事情拿来“吐槽”？ 主要是让我想起来之前我们老大带我们的时候，问过的一个问题：如果一个查询很慢，你会怎么优化？ 然后，最终告诉我们： 要学会做减法！ 想到这个之后， 我就觉得A耗费了2个多小时去解决那个bug， 他走的思路和方案， 跟我一直以来在做的，努力去优化的，是相反的。 然后，我也找一些人交流过怎么学习的问题，我发现，我的思路和想法，基本上都是比较“另类”的。
细说A的那个问题吧：他那个问题刚开始都没有被发现，因为程序运行不报错，后来是因为发现有一些错乱数据，简单来说， 就是本来我应该获取到List， 却结果，这个List里面的数据， 根本不是我想要的。 于是乎， A去查了数据库， 还查了缓存，查了服务器，当然，也查了代码。但就是一直没找到问题，觉得什么都很正常，这是一个不该出现的bug，称之为：玄学bug（用男票的话说）。 刚开始，A跟我说来着，我说要不要试试先把最基本的问题确认一下，看下那条线，定下几个节点，逐步查看每到一个节点，数据是否正确。别去搞那啥服务器了，先保证代码逻辑准确无误（我当时跟A说得是debug一下， 嘿嘿， 要是小花知道了， 估计又要说我了，然后大声说出： 要依靠日志，不要依赖debug）。 也许是一些程序员的通病吧，老觉得自己的代码是没问题的。当时就跟我说，不可能， 我查了代码，没问题（唉。。。。。。。。。。。。）
后来， bug解决了， 原因是什么呢： 本来该调用MehodA， 却然而，就是写了MethodB。。。。。。
这事儿不能算完了， 因为我发现， 在A解决问题的过程中，和之前老大带我们的时候告诫我们的不一样： 要做减法。 然后A似乎一直在做加法。
细分他的思路： 一会儿觉得是服务器有问题，一会儿觉得是数据库的数据有问题，一会儿觉得缓存有问题， 一会儿觉得代码可能真的有问题，还真的有考虑到网络有问题.......他的问题范围，一直都没有被缩小， 而且，未知的不确定越来越多。 如果他下次再遇到一个问题，极有可能要耗费更多的时间，甚至是一直找不到问题。
呃，实在是不得不歌颂一下老大了。 我记得之前老大跟我们一起探讨怎么解决一个问题的时候，就问过: 如果一个查询很慢，你会怎么优化？ (我写SQL一直不行滴)
我还记得那时候我们的团队里给出了好些个答案，大概就是： 去百度看看一般思路； 去查最终执行SQL，处理连接查询，加索引；索引是否命中；是否有锁，数据量是否过大；代码逻辑是否可以优化；添加缓存；查看数据库服务器的性能等等，好多个答案。 不可否认的是，这就跟穷举一样，只要有时间，问题肯定能被解决。 但是， 通常情况下，哪有那么多时间一个一个去试。 后来，老大就分享了一个思路：
为什么不先确定下来引起查询慢的可能原因呢？
为什么不把这些原因进行分类，比如说： 代码问题；服务器问题；SQL问题（连接、查询.....）等等。
为什么不去按自己划定的优先级和分类，去排除呢？
为什么不用最终的解决方案去完善自己的知识点呢？
这样子， 可能的情况，就会越来越少，而不是像我们之前说的那样， 一直在不断的往原因池里添加各种可能。
然后， 这就有一个问题，也是之前我跟大家交流后， 一个老被问到的问题： 红霞， 你不觉得，你的方案和思路，要耗费很多时间吗？ 有时候就是SQL错了，或者问一下（百度一下）就有答案了，却要花那么长的时间，去理思路和方案。而且，有时候可能最开始划出的范围，就很巧妙的把正确答案过滤掉了！还有就是， 这不管怎么样，都只是一个一个的去试，都是一样的。
其实也比较困惑。 有时候发现，的确如大家说的那样， 可能就是自己张嘴找问一下，或者百度搜几篇，试几下就知道答案了，然后我自己搁那儿从发出一个请求开始，慢慢统计可能经过的节点，可能会产生的问题，然后分类，补充自己之前 原因圈里没有的东西。 有时候， 我承认， 很有挫败感。 就是那种，明明再给我一点时间， 我就能推断到问题的所在了， 却总是被人捷足先登的解了bug。没有别的，就是很挫败，有时候，也在质疑自己的做法，就是我最终还是去问别人了，因为我百度不到，我也解决不了。（不是很紧急的时候，我会先去想这想那的。 如果很紧急的话，肯定是尽快解决问题，回头完善自己的知识点）
不过， 我是一个比较较真的人，也可以说是倔强，执着，无所谓了， 随便怎么说吧。 我就是一直在想，如果我百度解决不了问题， 为什么我一问头头儿， 他就能知道我百度不到的解决方案？ 他是怎么知道那个解决方案的，是经验的积累（以前遇到过），还是拥有一套属于自己的方法论？如果是经验的积累， 他是怎么获取经验的，又是怎么在他众多的经验中，定位到这一条解决方案的？如果是方法论，他的方法论是什么？又是怎么形成的？
我并不想知道具体一个问题的具体解决方案，这句话，我是认真的！ 一个问题发生了，解决它很重要，怎样去解决也很重要，但同样重要，甚至我觉得更重要的是：这个问题是怎么产生的？
因为我的这种解决问题的思路和方案，就会直接影响到我学一个东西的思路和方案。 这个和好些人都交流沟通过， 更是五花八门，我下篇博客要汇总一下自己的学习模式。
PS： 也会觉得，我不是一个真正的程序员。我或许应该更关注技术、代码的，但我确实更关心问题是怎么产生的，人又是怎么去解决的，妈蛋！