小扯一下调试。。。

前段时间陆陆续续读完了pangba老大力荐的Why Programs Fail, 一本关于程序调试的大作。给人最大的启发就是调试是一门科学而不是艺术。我从来不知道,原来调试还有那么多的千奇百怪的工具,可以写那么多的数学推导。从 小学开始我们就开始了解,作文没写好你可以说老师欣赏不了,而数学题算错了只能怪自己混的不够到位。于是我们总是很主观的把调试当成艺术来看待,调试能力 的高低不仅取决大量经验的积累也是天分所致。很遗憾的是,本书中告诉你,调试是有方法可以寻求的,像解数学题一样,用既定的方法套路去做,无论天赋高低经 验多寡,都能得到正确结果。恩,好像说的有点夸张了。但至少,调试是有章而寻的,是无须质疑的。我想我会努力去尝试使用一些书中提到的工具,但我依然不甘 心把一个充满所谓艺术性的活干的如此机械,书中的一些经验总结一下,同样可以在无足够工具支持下快速的进行调试。
TRAFFIC。这是作者把调试各步骤首字母提取出来的得到的一个词。依次对应跟踪问题,重现问题,自动化和简化,寻找感染源,专注可能的来源,分离感染链
问题跟踪,一个极其重要的内容是,错误是谁发现的。个人觉得,谁发现的直接影响到错误的可重现度。按可重现度高低来排,依次应该是自己发现》测试人员发 现》用户发现,而错误的可重现度,是影响调试时长(甚至是成功与否)的重要因素。换句话,如果想很好的调试,应该尽早的让潜在的错误跳出来和你对话,所有 为尽早发现错误进行的努力都是值得的。这些努力包括:断言,异常(你为什么不使用异常?),单元测试,重构,代码走查,静态分析等等。当你写下一些code的时候,你应该多考虑一点,如果出错,我是否能很快知道是这里出来的,这就是一个很好的习惯。
日志,我觉得其最重要的作用是用于重现问题阶段。它不应该作为个人编码阶段定位错误点、分析bug的最优先选择(当然这有太多的意外情况,比如你有很好的 日志分析和记录系统,或者没有其他更好手段可以使用等等...),而是应该作为重现客户问题的重要手段。在问题重现中,我们总是希望错误能在我这里明明白 白再出现一次,但很多时候这样小小的渴望都沦落成为了奢求。我曾做一个外包项目,在这里跑的好好的程序到美国那边总是出错。介于保密的原因,很多东西我们 不能够过多的了解,甚至连真实的数据我们都拿不到。这时候我们能够依仗的就是各种日志文件。通过日志,你可以在不重现错误的前提下推断出错误,不知其然却 知其所以然,未必不是解决问题的方法。
更多的时候,我们能够重现错误,但重现步骤过于繁杂(比如客户告诉你,他是一边倒立一边点鼠标发现这个错误的...),不能够帮我们很快定位在真实的错误 起始点上。这时候就需要进行简化,用到的是作者看家的兵器delta技术,有兴趣的可以翻书查看,而论其思想,主要是二分思路,或者说有条理有步骤的剔除 非相关因素。有条理有步骤是最关键的词汇,二分只是其中一种很步骤很条理的方式,而其他的,我觉得只要是够有规律,能够达到循序渐进,不走弯路的,都行。
书中描述了所谓的科学调试的方法。基本是按照回溯的路线(及从错误的出现点出发寻找错误的发起点...),提出假设,观察,验证或推翻假设,一直将假设等同于错误的起点为止。我觉得这也只是有步骤有条理的方式的很好的一种,而不是全部。
只是规规矩矩走路的人往往会错失捷径。我们很多时候看到这个错误出现,根本不用一步一步回溯,根据我们的经验和奔涌的肾上腺素,就能快速而准确的猜出问题 的原因,省时省力(该方法被称为快速而杂乱的调试...)。我想这是很多人(也包括我吧...)发掘问题起因的最习惯手段。而世界的残酷在于,一旦我们沉 迷于我们自己的猜测,会深陷其中,无法自拔,赌徒似的把大把大把的时间投进去,却血本无归。一个标准是,如果进行了十分钟的杂乱的调试依然没有找到问题的 话,就转入科学调试状态(把自己做成一个快表系统...),鱼和熊掌,就是这样来兼得。
此外,我们还有很多调试的手段,我觉得从目的上看可以分成事前推测和事后分析(还是那个WS的比喻,套&&药...~_~)。一个错误出 来,我们可以先走查一下代码,看看编译器的warning等等。书中最NB的,是一种静态分析技术,通过工具解析代码结构,得到一些可能的错误起因。在我 眼里,这就是所有事前分析手段的专业版本,有空我一定要玩玩这些工具。可惜的是,我们总是不能聪明到看(或自动分析)代码就可以了解所有错误的程度。很多 东西只有run起来,才有恍然大悟的机会。所以我们需要很多事后分析手段。用的最多的还是调试器。日志,对,也可以用在这里。两者最大区别时,调试器是精 确慢速而局部的,日志是粗犷全面但部署困难的。两者的使用,和场合和工具的犀利程度有很大关系。对我个人来说,在二者皆宜的场合,我会动用调试器。
说到调试器,不得不说测试(这里指的是程序员个人的单元测试...)。在此前一点概念需要说明。在很多人概念里,调试简单的对应使用调试器,与测试是格格 不入的。而在本书中,调试,指为了发现错误的起因所使用的所有手段,其中包含测试。测试最最最最优良的一点在于它是自动化的。或者说是可永远重现的。这就 是说,使用测试,可以帮你解决诱发错误,重现错误等及其麻烦的事情。但是,测试往往只是能够帮你找到错误的出现点,而不总是能快速的把你带到错误的起因 点,而为了部署这些测试你需要花费很多的精力。正是基于此,包括云风老大等很多人不屑使用测试(再次强调,这是指个人的单元测试...)。但是,这部以为这测试不重要,而成为你可以肆意偷懒放低代码质量的借口。而是因为其带来的好处被其他的一些技术抵消了,这样的话,为其付出的代价就会显得很沉重。
但是无论你使用什么样的手段进行调试。代码结构的质量才是最最最根本的内容。一个函数划分很细致,不大量滥用全局变量的代码,使用很多无副作用的函数,通 过测试你发现错误出现点,往往你就能很快到达错误起点(因为你把错误可能出现的地方限定在了有限的范围)。而如果你代码结构混沌不堪,函数/类之间关系错 综复杂,哪怕你用测试找到了错误出现点,开着调试器进去看,你也会很快转晕。所以提高代码质量,合理应用适合的调试工具和手段,正确使用调试的方法才是正 道。在这里,不得不提一下TDD。最初的时候我总觉得TDD最核心的是T,Test。后来才开始明白,它最核心的其实是D,Drive。你可以把测试写的 很弱,但你一定要在此影响下把代码重构的很好。由此得到一个蛮歪的理:如果你或你团队的代码素质很高,可以尝试不用TDD的一些开发手段;但如果你或你团 队代码素质不够高,请把自己套在TDD里面磨练一下。之所以说歪,是因为我其实只想说后半句,前半句纯属为了对仗工整而用。
最后我发现我忘提一个很好玩的东西,断言。我一直觉得这个东西很有意思。是一种游离在单元测试与调试器之外的手段,是一个隐藏在事后分析中的事前推测派来 的间谍。assert的意义在于猜测并提醒一些最有可能的错误,它不精确但也不死板。我一直觉得,全面合理的铺下断言这张网(三个部分,输入输出不变 式),可以很有效的提高调试速度。

posted on 2008-03-16 04:07 duguguiyu 阅读(...) 评论(...) 编辑 收藏

导航

统计