您的位置:知识库 » 软件设计

修复Bug好比钓鱼

作者: Jim Bird  来源: CSDN  发布时间: 2012-09-13 10:43  阅读: 5381 次  推荐: 18   原文链接   [收藏]  

  英文原文:Fixing a Bug is Like Catching a Fish

经理:该Bug何时能得到修复?

经验缺乏的程序员:也许一个小时?最多两个小时!马上去做!

经验丰富的程序员:嗯,捉一条鱼需要多少时间呢

  在现实操作中,很难能明确知道一个软件缺陷需要多久可以修复,尤其是当你对代码不了解的情况下。James Shore在“敏捷开发艺术”一书中指出:“在你需要修复Bug时,你必须找到是哪里出错了?”,问题的关键是不能准确估算多久才能找出是哪里报错的。只有知道“病源”在哪?你才能准确估算修复的时间。但那为时已晚,根据Steve McConnell

“发现缺陷——理解缺陷——通常占了工作的90%”。

  有许多缺陷只需要改一行代码就可以修复。时间都花在确定该行上面,就好像钓鱼的时候该把鱼钩放哪?何时何地鱼会上钩一样。每个Bug都有它们自己的性格特征,有些可能很容易被发现,而有些可能会跟你玩“捉迷藏”,并且容易发现的Bug不一定就很难修复,当然,那些擅长玩“隐藏”的Bug有可能很容易被修复。

  查找和修复

  下面让我们来看看如何发现并修复Bug。当调试时,Paul Butcher把每个步骤都进行了很好的描述。经验丰富的程序员会很熟悉这种结构化和纪律性的步骤要领。

  1. 确定查找目标,审查Bug报告,看看该Bug描述是否很合理并且提供了足够的信息去发现和重现。检查一下该报告以前是否遇到过,如果是,可以检查以前是如何处理的。
  2. 清理桌面——找到正确的代码并检查、清理工作空间。
  3. 设置与之匹配的测试环境。这可能是微不足道的,或者是不可能出现的,如果客户是在一个你无法访问的配置下运行。
  4. 对代码的理解已经毫无问题,并且通过现有的测试套件。
  5. 钓鱼的时间到了,重现并且诊断错误。如果你不能重现这个错误,那么就无法去修复。
  6. 写新的(失败的)开发测试报告或者修复现有测试报告来捕捉Bug。
  7. 进行修复——确定没有破坏其他功能模块。这里可能会包括,在修复之前对代码进行重构使代码更容易被理解,并且使整个修复更安全。在后面的回归测试中确保没有引入任何新的错误。
  8. 努力让代码更安全,更清洁,做一些循序渐进的重构确保代码更健壮并且易于维护的。
  9. 修复完成后,让他人进行审查,确保你没有做一些愚蠢的事情。
  10. 再次检查。
  11. 检查该Bug在其他分支中是否存在,如果你不是主线,你可以在里面进行合并,然后在代码里面进行处理,并且浏览所有相同的评论和测试报告。
  12. 结束并且进行思考和总结。明白是哪里出错了?为什么?是否真正理解自己的修复?在别的地方还会发现这个错误吗?在Pragmatic Programmer,Andy Hunt和Dave Thomas也同样问了这样的问题:“如果你花了很长时间去修复这个Bug,问问自己,到底是为什么?”在将来,如何让该Bug更容易被发现和修复?如何提高修复方法或许是使用工具?思考的是否深入,要看这个Bug影响和所花的时间有多长?

  发现和修复需要多久

  设置测试环境所需的时间,重现一个Bug或者修复可能远远超过在代码中查找和修复的时间。但是对于那种小缺陷,在发现时即可修复。

  在软件开发中,关于大多数软件缺陷来自哪里?Dewayne Perry解释到:发现一个Bug(理解并重现Bug)比多久去修复更难。研究发现,大多数Bug(几乎3/4)很容易被发现和理解,并且不会花多少时间去修复:5天或更少(这是在大型实时系统与一个重量级的SDLC中,经过大量检查和测试发现的)。这里有一个长期隐藏型Bug,可能需要花更长的时间修复,即使这个Bug微不足道:

发现/修复工作 小于5天修复 大于5天
缺陷可以重现 72.5% 18.4%
很难或者不能重现 5.9% 3.2%

  所以在你发现Bug的时候,可以和自己打赌,它很快就会被修复,这个命中率会很高。但是当打赌失败时,你可能会错很多,或者彻底来个大错特错。

18
0
标签:Bug 调试 测试

软件设计热门文章

    软件设计最新文章

      最新新闻

        热门新闻