时常有朋友发邮件给我，说遇到了一个什么什么奇怪的问题，不知道是怎么回事，希望我帮忙看看。我基本上每天都会抽出或长或短的时间来回复这些邮件，不过也经常发现，其实许许多多的问题都完全是有能力自行解决的。在很多时候，我发现许多朋友还缺乏最基本的解决问题，分析问题的方式。其实我在平时工作中也会遇到各种各样的问题，有时候甚至异常古怪，但是在仔细分析之下，往往都能解决。于是我现在打算谈点解决问题的基本方式，希望可以帮到一些朋友。
如果您也有着方面的体会，也可以分享一下，即使是某个简单案例也是很有帮助的。
要解决问题，首先是要定位问题，配合正确的推理方式，再仔细分析，“动手尝试”很可能只是验证推理是否正确的手段而已，其实大部分的情况都可以用思考来得出（或排除）。要定位问题，很重要的一点便是要把概念理清。很多朋友会轻视概念，认为那种“理论”有什么重要的，最关键的是“动手”——但殊不知概念能让您的“动手”少走很多弯路。
例如，在一个问题出现之后，我往往会心想，这到底是“开发时”还是“运行时”的问题。我们在做开发时会用到许多概念，有些是“开发时”的概念，有些则是“运行时”的概念。我们开发会用到很多工具，Visual Studio是一个大工具，但是它也会把很多功能，如“编译”等操作委托给外部的命令，VS只负责捕获那些输出而已。而在运行的时候，根本不会关VS什么事情。之前我写过一篇文章，指出csproj，sln等等都是开发时的概念，它们离开了Visual Studio，MSBuild等开发工具之后，就没有任何作用了。同样，“项目模板”也是Vistual Studio才知道的东西，而运行的根本不会关心所谓的ASP.NET Web Site还是Web Application。
于是，许多问题的排错就可以有大致的方向了。许多做ASP.NET的朋友都会问：“为什么我创建的ASP.NET AJAX项目可以运行”，但是用“ASP.NET Web Application”创建的项目就没法使用ASP.NET AJAX了呢？很明显，这个问题的关键不在“使用什么模板创建的项目”，而是这个项目中的内容是否可以执行，更确切地说，是某个文件夹下的内容能否使用 ASP.NET AJAX——因为对于IIS来说，它不会关心“项目”（也就是csproj文件）在管理哪些资源，它只知道“网站目录”。
好，既然知道是网站内容的问题，那么接下来就应该比较的是“一个可以运行的网站”和“一个不能运行的网站”究竟有什么区别。ASP.NET站点最关键的东西便在于web.config，“能够运行”往往也是web.config来决定的。例如，你有没有正确配置HttpModule或HttpHandler。在许多情况下，解决了ASP.NET站点的web.config，问题也就解决了大半。同样的情况还会有，为什么同样的代码（标记）在有的aspx上就能解析成功，有的就不行？那可能是web.config中没有引入正确的control标记或命名空间造成的。
有朋友可能会说，你知道 web.config的那么多节点是做什么的，自然容易排错，我都不知道，怎么知道问题在哪里？其实，我也不知道很多东西，但是我会比较。我一开始用VS 写F#程序的时候，都只是用一个文件来练习。后来想要用多个模块了，于是就创建新的源文件。但是我发现，main方法总是说写在新文件里的模块“还没有定义”，这让我很困惑。于是乎，我去网上找一些示例——不是普通代码片断，而是一些用VS编辑的小型项目，它们自然是能够编译通过的。例如，我拿到了项目 A，我就开始比较它和我的写法究竟有什么问题——观察下来没有任何收获，我还是觉得我的做法没有任何问题。于是我尝试着在A项目中添加我的模块——奇怪，在A的main方法中还是访问不到新模块——这不是欺负人么！
于是我进行更深入的比较，比较除了源文件之外，它的项目设置和我的项目设置有什么区别——还是没有！我抱着最后一丝希望，将A项目中的代码添加到我的项目中来，编译，还是失败！但是看到这个结果，我反而看到了解决问题的曙光。因为我都已经把源代码统一了，这样可能发生错误的地方可谓少之又少。刚才我提到，VS将编译工作交给外部命令执行，对于F#也一样。于是我就比较项目A和我的项目在编译时的输出，终于发现两者的区别在于调用fsc.exe的时候，参数顺序不同。F#的编译器和C#编译器不同的地方在于，它对源文件指定的顺序是有要求的，只有放在后面文件中的代码才能访问到前面文件中定义的内容，反之则不行。这意味着，main方法必须作为最后一个源文件存在。但是，VS并没有提供一个选项来调整源文件的顺序，既然这样，那就手动编辑fsproj文件吧。至此，问题解决。
我被这个问题困扰很久的原因，就是在于我从来没有去怀疑过F#编译器对源文件的指定顺序是有要求的。我之前也观察过fsc.exe的参数，但是并没有“看出”什么问题出来。但是，我会和一个成功的项目慢慢比较，把我的项目和它慢慢靠拢，我用这种方式排除了各种错误可能性，最终把我的关注点又“逼迫”到编译器的参数上。进行比较，尝试，最终解决问题。再此之前，我也不知道这一点，不是吗？您其实也一样，如果遇到了一个奇怪的问题，没关系，找一个成功的案例，详细比较为什么它能行而我不行，慢慢地向它靠拢。最终解决问题的时候，就是你获得新知识的时候。这样，你的“经验”增加了。
类似的做法还有：不时有朋友会问到，它的 WebForm项目出现了这样那样的问题，例如在PostBack之后事件没有执行，状态没有恢复，读不到某个值等等。从我的经验上来说，这是遇到了生命周期的问题。但是，生命周期是个复杂的玩意儿，除非我亲手进行尝试，我也不可能知道某个特定项目特定问题的解决方案。其实对于这种问题，最好的方法之一，便是从最简化的模型开始尝试。例如，您可以准备一个空白页面，添加一些控件和代码，执行，成功。然后，您将这个简单的页面向您的项目进行靠拢，一次增加一小部分，然后执行看看是否成功。直到某段代码添加之后发现失败了，您就知道到底是什么原因引起的。可能是新的代码有问题，也可能是新代码让之前代码的问题暴露出来了。
对于排错来说，最关键的是思考和分析，而不是动手。我有时候见到一些同事在遇到错误之后就开始盲目地修改代码，重试，最后就算把问题碰对了，时间也浪费了——而且还可能把原有正确的地方改坏了。要进行思考和分析，就要细心观察，例如您有没有看清异常的信息是什么？有没有顺着InnerException一级一级往下看，看看最终是哪行代码出的问题？如今的框架，一般都会把错误信息写的非常完整。记得之前做WCF的时候，它甚至会告诉你可以尝试着修改配置中的哪个节点！如果您直接忽视这些，就丧失了第一手信息了。
还有，别怕英文，就个错误信息而已，没几个词的。
但是我可以这么说，许多朋友都缺少思考。因为从他们给我的邮件上来看，根本没有把问题描述清楚。我相信“如果说不清楚，那说明没想清楚”。事实上，如果能把问题描述清楚了，一般也可以找出用什么关键字去搜索引擎上查找信息。我很奇怪，许多朋友还不会用搜索引擎，例如他们会对搜索引擎说很长一句话，而不是提取出中间的“关键字”进行查询。更严重的问题是“造词”。例如“注入”，这个词很流行啊，脚本注入，SQL注入。于是很多人在提问的时候也一直“注入”，但事实上他的问题和任何一种“现存的注入”的含义都不同。当然，您觉得这是“注入”也没有关系，但是至少描述一下在您的场景下“注入”是什么意思，对不对？而且，如果你用“注入”去搜索引擎上查询，就会发现基本上找不到你想要的东西，因为“注入”这个词在互联网上有别的含义，它和你的含义完全不同，又能给你什么信息呢？
此外，查到内容之后，也要进行基本的信息筛选。例如，一些小站，垃圾站的信息就不要关心了吧。直接找一些著名的大站，如官方社区，文档，博客就行了。
最后一点是为我个人而说的。如果您希望让我分析代码，还请把所有可运行的东西打一个包给我，并告诉一个略为详细的步骤，让我可以直接双击打开编译执行并重现问题。如果您只给我一个代码片断，还无法编译通过，或者还需要我自己去补充各类库，那我就只能说声抱歉了。同样，如果涉及到数据库，那么请给一个用于创建脚本和测试数据的SQL文件。此外，如果项目太大，最好也新建一个项目，只放一些核心的东西即可，关键在于重现问题。而且就我个人经验来说，经过“提炼” 之后，说不定您自己就已经发现问题所在了。
原文链接：http://www.cnblogs.com/JeffreyZhao/archive/2009/10/14/about-debugging.html
