首先，这篇文章是一篇枯燥的方法论，或许你会不喜欢，但是我还是建议你看下去。因为这些方法论不是由哪个家哪个家研究出来的长篇大论，而是一个软件开发者的切心体会。
这里的“问题”，你可以理解是一个恼人的bug
，或者其他难以解决的东西。
好吧，不说那么多，直入主题。
确定问题域
首先确定问题域。
最开始我以为这个词是我凭空想象的，写这段话的时候，顺便问了一下百度。百度上这么解释：问题域”
指提问的范围、问题之间的内在的关系和逻辑可能性空间。 软件工程：在软件工程中，问题域是指被开发系统的应用领域，即在客观世界中由该系统处理的业务范围。在这里，我想表达的是这么一个意思：一个bug
的出现，必定是在某一个地方，确定问题域，就是确定并明确该问题是有哪部分的错误引起的。比如说，我们写了简单的加和功能，然后在主程序中输出结果。发现输出不对，然后调试发现加和函数返回结果没有问题，那么我们就可以将问题域确定在输出那一块上。刚开始确定的问题域可能很大，不过这不要紧，接下来我们要做的就是缩小问题域。
缩小问题域
我个人认为，如果你能够很成功的缩小问题域，那么这个问题也就基本上能够很快的解决了。
当你解决一个你特别熟悉的问题时，你会不自觉的使用该方法，因为有你潜在的经验在。可是如果遇到的是一个你所不熟悉的问题，有可能你就找不到解决的办法了。
如何缩小问题域呢？假设，我们将一个问题描述问题Q
，那么Q
肯定是由各种小的模块组成的。并不是每一个模块都有bug
，也不是只有一个模块有bug
。特别是后者，如果一个问题是由多个bug
导致的，修复起来就很有难度。
我们现在假定这个问题的模块组成结构图如下所示。
可以看出来，这个问题还是比较复杂的。Ok，现在我们在Q处发现一个bug。然而对于这样的bug，我们毫无经验。以前我可能会按照Q的错误提示，然后，在网上狂找答案，得到各种答案后，进行各种尝试。所有的尝试都是盲目性的尝试。而且每次的尝试，都是单变量的，比如说，就如Q的问题。可能有的是因为A处出错了，但是就Q问题本省，可能是由于A，E共同导致的。这样查起来就很有难度了。
这里提供几种排查问题的方案。
如果你有一个模版例子，跟这个相似，那么你可以很好的利用一下。比如说，范例的使用也是同上的形式，D+F+A共同作用导出Q。那么，你将自己代码取一部分放进去。比如，将F放过去，如果没错，那么肯定是D和A出错了。然后再使用模版的A与F组合，加上我们自己写的D，如果有错，那么就是C或者D的构造出错。如果没错，说明D本身没错，单个A的使用出错了。这样不断的将问题域缩小，逐步相互比较，在那个地方出错了，就不断追溯这个错误的原因。直到最终错误成为某一个点。然后将这个错误和原有的范例进行比较，看看差异在哪里。
或者是你将该部分有错误的代码放在一个最单纯的环境中，比如说控制台。这样去逐步确定产生该问题的原因。减少项目本身的一些原因对bug
寻找造成的影响。
其实，在缩小问题域的过程中，一定要先确定好自己的缩小方案，一步一步来，每一步执行结果都要应该有一个可靠的推论，对下一步的确定方案进行指导。而万万不能是盲目的修改，连自己都不知道如果这个不成功我下一步该怎么办，只是祈祷这一次修改恰好是错误的地方。
修复问题
找到问题的所在的时候，就剩下最后一个问题了，就是修复该bug
。
修复该bug最直接的方案就是有什么错，就纠正什么。通常这么做就能解决问题。但是，我这里要说的是，并不是所有问题都是非得通过这个方法解决，或许我们可以从根本上替换了某个方法，而避免引入这个bug，没有了这个bug，也就无修复所言了。这也是我在开发中经常泛的一个错误：遇到一个问题，就想这要解决，却很少及时的想起换一套解决方案，把这个问题绕过去。O()︿︶)o 唉，没办法，感觉遇到一个问题，就怎么能置之不理呢？再想想想，这不过是 学术而另一个是技巧罢了。
最后
写了这么多，到最后才发现，把这些用文字表达出来是这个苍白无力，像是大白话。没办法，是不是所有的理论原理都这样，或许只有自己体会出来的东西，才会最明白。
嗯，大概是这样。
本文转自HDDevTeam 51CTO博客，原文链接：http://blog.51cto.com/hddev/681380，如需转载请自行联系原作者
