关于排错:专注思考,细心观察,步步为营
时常有朋友发邮件给我,说遇到了一个什么什么奇怪的问题,不知道是怎么回事,希望我帮忙看看。我基本上每天都会抽出或长或短的时间来回复这些邮件,不过也经常发现,其实许许多多的问题都完全是有能力自行解决的。在很多时候,我发现许多朋友还缺乏最基本的解决问题,分析问题的方式。其实我在平时工作中也会遇到各种各样的问题,有时候甚至异常古怪,但是在仔细分析之下,往往都能解决。于是我现在打算谈点解决问题的基本方式,希望可以帮到一些朋友。
如果您也有着方面的体会,也可以分享一下,即使是某个简单案例也是很有帮助的。
要解决问题,首先是要定位问题,配合正确的推理方式,再仔细分析,“动手尝试”很可能只是验证推理是否正确的手段而已,其实大部分的情况都可以用思考来得出(或排除)。要定位问题,很重要的一点便是要把概念理清。很多朋友会轻视概念,认为那种“理论”有什么重要的,最关键的是“动手”——但殊不知概念能让您的“动手”少走很多弯路。
例如,在一个问题出现之后,我往往会心想,这到底是“开发时”还是“运行时”的问题。我们在做开发时会用到许多概念,有些是“开发时”的概念,有些则是“运行时”的概念。我们开发会用到很多工具,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文件。此外,如果项目太大,最好也新建一个项目,只放一些核心的东西即可,关键在于重现问题。而且就我个人经验来说,经过“提炼”之后,说不定您自己就已经发现问题所在了。
Jeffrey Zhao
![software-testing software-testing](http://www.7yit.com/wp-content/uploads/2012/10/software-testing-262x300.jpg)