你知道“查找和修复bug”意味着什么吗？没错，就是调试！不断的调试，无数次的调试！大牛通过大量工作，总结出以下结构化的步骤，下面蓝鸥广州html5开发培训机构就为大家转发分享一下：
1.明确目的。仔细查阅异常报告，确定是否是个bug，找出各种有用的信息发现问题的症结，予以重现。再次检查是否与报告发生重复。如果发生重复，那看看曾经的相关人员是如何处理的。
2.准备工作——找出正确的代码，用排除法清理工作区域。
3.匹配测试环境。如果客户正在操作计算机配置，那么此过程可以跳跃。
4.明确代码的用途，确保现有测试工具一切正常。
5.好了，现在可以出发钓鱼去咯——重现和诊断错误。如果你不能做到重现，那你就不能证明你已经完成修复工作。
6.编写测试案例，或者通过现成的测试案例来捕获bug。
7.进入修复模式——请务必确保不会影响到其他任何部分。但是，在开展修复工作之前，可能你还要包揽重构工作，因为只有这样，你才能无所顾忌地捣鼓代码。而且事后回归测试，还能确保你不会加入任何新的bug。
8.整理代码。通过一步一步重构，让你的代码更易于理解，更安全。
9.找别人来审查一下，当局者迷旁观者清。
10.再次检查此修复过程。
11.试着不从主线出发，以检查这些bug是否会影响其他支线。合并这些变化，处理代码中的差异，回顾所有的审查和测试等工作。
12.思考。好好想一想哪里错了以及为什么错了？为什么你的修复会起效？这种类型的bug还会出现在哪里？在《 The Pragmatic Programmer》一书中，Andy Hunt 和Dave Thomas也如是指出“如果一个bug需要耗费你很多时间，那么一定要好好弄清楚原因”。
此外，还需要思考的是，怎么做才能吸取经验教训，将来在类似的问题上不再栽跟头？以及，我们采用的方法、使用的工具是否还有可以改进的地方？以及这些bug的影响和严重程度。
找到bug，还是修复bug，哪个需要更多时间？
或许建立一个测试环境、重现问题和测试bug所需的时间，要远远多于找到bug和修复bug的时间。不过对于一小部分显而易见的bug，找到它们很简单——不过修复起来可能就不尽如人意了。
在《Making Software》一书中，有一章主要是探讨“大部分的软件漏洞的来源”，Dewayne Perry分析认为，相较于修复，发现bug（包括理解bug和重现bug）所需时间更长。有研究表明，大多数的bug（差不多有3/4）既易于发现又易于修复：5天或许更少（这是基于大规模实时系统通过重量级SDLC、大量审查和测试得出的数据）。但是也有很恶心的bug，即便你可以轻轻松松揪到它，还是还得“呕心沥血”才能修复好。
所以如果你打赌说你能很快修复bug，大多数情况下你还真没说错。不过当你打赌输了的时候，那么，嘿嘿，就意味着你有大麻烦了。
所以，下次，boss再问什么时候能修复bug，别再傻乎乎地回答“马上就能搞定”了。
如果对编程感兴趣，想了解更多的编程知识，解决编程问题，以及入门指导，帮你解决编程中遇到的困惑，蓝鸥广州web前端培训机构的培训开发项目全部来自于真实的企业项目，单独项目代码量超过5万行。为了让学员尽快的进入到企业开发的项目中，蓝鸥使用自主开发的产品和为客户定制的企业产品为案例，大批蓝鸥HTML5培训开发学员都从中收益。
