修复Bug好比钓鱼
openkk 12年前
<p> 原文：<a href="/misc/goto?guid=4958521710438033664" rel="nofollow" target="_blank">Fixing a Bug is Like Catching a Fish</a></p> <p> <strong>经理</strong>：该 Bug 何时能得到修复？</p> <p> <strong>经验缺乏的程序员</strong>：也许一个小时？最多两个小时！马上去做！</p> <p> <strong>经验丰富的程序员</strong>：嗯，<a href="/misc/goto?guid=4958521710534195062" rel="nofollow" target="_blank">捉一条鱼需要多少时间呢</a>？</p> <p> 在现实操作中，很难能明确知道一个软件缺陷需要多久可以修复，尤其是当你对代码不了解的情况下。James Shore 在“<a href="/misc/goto?guid=4958521710621446819" rel="nofollow" target="_blank">敏捷开发艺术</a>”一书中指出：“在你需要修复 Bug 时，你必须找到是哪里出错了？”，问题的关键是不能准确估算多久才能找出是哪里报错的。只有知道“病源”在哪？你才能准确估算修复的时间。但那为时已晚，根据 <a href="/misc/goto?guid=4958521710713403290" rel="nofollow" target="_blank">Steve McConnell</a>：</p> <p> “发现缺陷—理解缺陷—通常占了工作的 90%”。</p> <p> 有许多缺陷只需要改一行代码就可以修复。时间都花在确定该行上面，就好像钓鱼的时候该把鱼钩放哪？何时何地鱼会上钩一样。每个 Bug 都有它们自己的性格特征，有些可能很容易被发现，而有些可能会跟你玩“捉迷藏”并且容易发现的 Bug 不一定就很难修复，当然，那些擅长玩“隐藏”的 Bug 有可能很容易被修复。</p> <p style="text-align:center;"><a title="修复 Bug 好比钓鱼" rel="lightbox[24788]"><img title="修复 Bug 好比钓鱼" alt="修复Bug好比钓鱼" src="https://simg.open-open.com/show/8ce3ddbd5ada98310a3cdc97fa7cec48.jpg" width="232" height="290" /></a></p> <p> <strong>查找和修复</strong></p> <p> 下面让我们来看看如何发现并修复 Bug。当<a href="/misc/goto?guid=4958521710804385348" rel="nofollow" target="_blank">调试</a>时，Paul Butcher 把每个步骤都进行了很好的描述。经验丰富的程序员会很熟悉这种结构化和纪律性的步骤要领。</p> <p> 1. 确定查找目标，审查 Bug 报告，看看该 Bug 描述是否很合理并且提供了足够的信息去发现和重现。检查一下该报告以前是否遇到过，如果是，可以检查以前是如何处理的。</p> <p> 2. 清理桌面——找到正确的代码并检查、清理工作空间。</p> <p> 3. 设置与之匹配的测试环境。这可能是微不足道的，或者是不可能出现的，如果客户是在一个你无法访问的配置下运行。</p> <p> 4. 对代码的理解已经毫无问题，并且通过现有的测试套件。</p> <p> 5. 钓鱼的时间到了，重现并且诊断错误。如果你不能重现这个错误，那么就无法去修复。</p> <p> 6. 写新的（失败的）开发测试报告或者修复现有测试报告来捕捉 Bug。</p> <p> 7. 进行修复——确定没有破坏其他功能模块。这里可能会包括，在修复之前对代码进行<a title="重构" href="http://www.amazon.cn/gp/product/B003BY6PLK/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&tag=vastwork-23&linkCode=as2&camp=536&creative=3200&creativeASIN=B003BY6PLK" rel="nofollow" target="_blank">重构</a>使代码更容易被理解，并且使整个修复更安全。在后面的回归测试中确保没有引入任何新的错误。</p> <p> 8. 努力让代码更安全，更清洁，做一些循序渐进的重构确保代码更健壮并且易于维护的。</p> <p> 9. 修复完成后，让他人进行审查，确保你没有做一些愚蠢的事情。</p> <p> 10. 再次检查。</p> <p> 11. 检查该 Bug 在其他分支中是否存在，如果你不是主线，你可以在里面进行合并然后在代码里面进行处理并且浏览所有相同的评论和测试报告。</p> <p> 12. 结束并且进行思考和总结。明白是哪里出错了？为什么？是否真正理解自己的修复？在别的地方还会发现这个错误吗？在 <a href="/misc/goto?guid=4958521710925133672" rel="nofollow" target="_blank">Pragmatic Programmer</a>，Andy Hunt 和 Dave Thomas 也同样问了这样的问题：“如果你花了很长时间去修复这个 Bug，问问自己，到底是为什么？”在将来，如何让该 Bug 更容易被发现和修复？如何提高修复方法或许是使用工具？思考的是否深入，要看这个 Bug 影响和所花的时间有多长？</p> <p> <strong>发现和修复需要多久</strong></p> <p> 设置测试环境所需的时间，重现一个 Bug 或者修复可能远远超过在代码中查找和修复的时间。但是对于那种小缺陷，在发现时即可修复。</p> <p> 在软件开发中，关于<a href="http://books.google.com/books?id=DxuGi5h2-HEC&pg=PA453&lpg=PA453&dq=making+software+where+do+most+software+flaws+come+from&source=bl&ots=0UrwmjS6pS&sig=SPfhxYlh25EUqjGP6fC7XYmsi54&hl=en&ei=Pe_gTv9U4_PSAZ3cucYH&sa=X&oi=book_result&ct=result&resnum=2&ved=0CCMQ6AEwAQ#v=onepage&q=making%20software%20where%20do%20most%20software%20flaws%20come%20from&f=false" rel="nofollow" target="_blank">大多数软件缺陷来自哪里</a>？Dewayne Perry 解释到：发现一个 Bug（理解并重现 Bug）比多久去修复更难。研究发现，大多数 Bug（几乎3/4）很容易被发现和理解，并且不会花多少时间去修复：5天或更少（这是在大型实时系统与一个重量级的 SDLC 中，经过大量检查和测试发现的）。这里有一个长期隐藏型 Bug，可能需要花更长的时间修复，即使这个 Bug 微不足道：</p> <table style="width:400px;" border="1" cellspacing="1" cellpadding="1" align="center"> <tbody> <tr> <td><strong>发现/修复工作</strong></td> <td width="100"><strong>小于 5 天修复</strong></td> <td width="100"><strong>大于 5 天</strong></td> </tr> <tr> <td>缺陷可以重现</td> <td>72. 5%</td> <td>18. 4%</td> </tr> <tr> <td>很难或者不能重现</td> <td>5. 9%</td> <td>3. 2%</td> </tr> </tbody> </table> <p> 所以在你发现 Bug 的时候，可以和自己打赌，它很快就会被修复，这个命中率会很高。但是当打赌失败时，你可能会错很多，或者彻底来个大错特错。</p> <div id="come_from"> 来自: <a id="link_source2" href="http://blog.jobbole.com/24788/?utm_source=rss&utm_medium=rss&utm_campaign=%25e4%25bf%25ae%25e5%25a4%258dbug%25e5%25a5%25bd%25e6%25af%2594%25e9%2592%2593%25e9%25b1%25bc" target="_blank">blog.jobbole.com</a> </div>