专注思考,细心观察,步步为营

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

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

Grow your business fast with

Suku