修复bug与解决问题

　　这篇文章能读者更好地理解造成bug产生的一些问题，并相应地修复bug能够起到一些好的作用。希望对大家有用，所以大家要认真阅读噢~
　　什么是bug？
　　在软件工业中，一个bug可以代表任何形式的系统错误（NullPointerException、Http 404错误代码或是蓝屏……）、功能性错误（在我单击B的时候，系统本应执行Z，却最终执行了Y）、性能问题以及配置错误等等。
　　在精益的术语中，一个bug必须能够按照下一节提到的定义进行清晰的表达，才能说它是一个问题。请相信我，我所见过的（和自己产生的）bug中，95%以上都不像是某种问题——性能问题或许是个常见的例外情况，但有趣的是，它们也是绩效的一部分，不是吗？

　　boss：那么，你需要多长时间来修复这个 bug？
　　没有经验的程序员：给我一个小时？最多两个小时？我能马上搞定它！
　　有经验的程序员：这么说吧，钓到一条鱼要多久我就要多久？！
　　要多少时间才能修复bug，事先是很难知道的，特别是如果你和这些代码还素不相识的话，情况就更加扑朔迷离了。要想修复问题得先知道问题的所在，而我们之所以无法准确估计时间是因为我们不知道需要多久才能发现症结的所在，只有清楚这一点，我们才能合理估计修复 bug 所需要花费的时间。不过，这个时候恐怕黄花菜都凉了。
　　怎样从bug中分析问题所在？
　　Bug的出现往往是系统中产生了更常见问题的一种症状，而对于精益团队来说，将这些症状与真正的问题相关联起来是至关重要的。可以这么说，正如米开朗基罗从大理石碎片中发现它的美丽，并最终打造成迷人的雕像一样，精益团队的任务（例如某些团队会将持续改进作为他们每日工作内容的一部分）就是发挥他们的洞察力，从大量的bug中发现问题，并将其抽取出来。实现这一点需要进行细致地分析，并将这些原始的问题转化为学习的机会。
　　我发现了一种着手进行这种分析的良好方式，就是将所有bug分门别类，并且理解每个bug类别的权重。大多数情况下，某个bug类别就体现了造成某个现有问题的原因，或者它本身就是一个问题。这种关联性可以帮助你以正确的顺序处理这些问题，并首先从对整个操作绩效影响最大的问题开始解决。如果你仍然不确定应该从何处着手，那么优先解决质量问题是比较保险的做法。
　　Steve McConnell 曾说过：“发现问题—理解问题—这就是程序员90％的工作。”很多bug都只需改动某一行代码即可。但是需要投入大量时间的是，后面还得指出怎么样才是正确的——就像我们在钓鱼的时候，得知道往哪里下诱饵，什么时候鱼儿容易上钩等等。
　　

　　示例1：敏捷开发中的情景
　　当时我在这个使用敏捷开发的团队中担任经理一职。和许多团队一样，我们团队也不是一个跨职能的团队（典型的Scrum-but），而是一个负责后台的团队。它在某个迭代内负责构建基础服务端软件，以便让应用团队在之后的迭代中使用这部分功能。
　　我们按照Paretos原则（即80-20原则）对产生的bug进行了一些分析，并且找出了一个占总数约20%的bug类别：这些bug都是由应用团队所提出的，与我们团队所建立的后台软件所暴露的API对“隐式”这一概念的定义有关。当应用团队在使用我们提供的功能时，经常会发生遗漏了某些输入参数，或者是缺少了某些输出数据等问题……因此他们就会为我们创建一些bug，而我们的团队则会说：嘿！这个API已经隐式地表明了它不会返回这些数据。
　　我们同时注意到了这些bug的持续时间，通常从创建直到关闭为止一共持续了大约4个星期。（在最好的情况下）在以一个月为周期的迭代的最后阶段会进行代码发布，客户端团队则可以在下一个迭代时使用这些代码。因此当客户端团队创建了bug，并指派给原来的开发者时，往往距离她开发那些代码时已经过去了两三个星期，开发者不得不再度拾起这段代码……
　　为了处理这种情况，我们决定改变一下工作的方式，将相关人员组织在一起，而产生一个相关联、跨职能并且跨技能的团队。
　　采用了新的方式之后，我们注意到这些“隐式API”相关的bug数量大幅下降了（约50%）。最令人欣慰的是，这种类型的bug的持续时间下降到了几个工作日以内。当然，这个数字有一定的水分，有些bug虽然被发现了，但是并没有记录下来，因为开发者们现在进行结对编程，于是许多bug直接在座位上就解决了。
　　虽然成果是显著的，但我总感觉到还有些不适之处，却说不出究竟是哪里出了问题。之后不久我才发觉，从精益的角度来说，我们目前还有两个不足之处：
　　首先，我们的系统中依然存在bug，因此我们不得不重复劳动，这使得整个开发系统出现了生产力的浪费。但是由于缺乏内建的质量标准，我们无法保证服务端开发者所开发的API不存在问题。此外，对于错误的处理也没有真正的标准，我们的解决手段就是：遇到问题就坐下来一起解决。
　　尽管结果非常显著且令人振奋，但它与团队的每日绩效没并有什么直接的关联，团队也无法立即采取行动并在第二天直接看到结果。我们只是从宏观上在6个月结束后的发布中才能够看到这一效果：即在bug总数中与API相关的bug只占少数。因此我们看到：建立一个跨技能的团队确实能够在某种程度上改进质量，但我们还未能提供一种有效的方法，让我们能够每天监控它的情况，并采取相应的行动。
　　示例2：精益开发中的情景
　　时间转眼间过去了几年，我还是任职于同一家公司中，但目前的职位是项目主管及教练，负责一个大型的多团队、多种技术的敏捷项目的实施。某一个团队遇到了一个很有挑战的技术难题，他们要与某个大家都没有什么经验的技术进行整合。整个团队在过去的两个Sprint中没有交付任何用户故事，他们深陷于质量问题（例如bug）中难以自拨。当第二个Sprint结束后，依然没有任何完成的用户故事（比方说，按照我们对完成的定义来看，该用户故事在功能性需求上需要做到没有任何bug）可以交付。因此在回顾会议中，整个团队一致决定，将每周进行bug评审（在精益中称为红箱分析）。
　　在第一次会议中，团队为所遇到的问题建立了一个Pareto模型。我们创建了一张表格，将bug类别放在一列里，bug的数量和bug ID则分别用余下的几列来表示。
　　之后的目标是逐个排除每种bug类别背后的根本问题，首先从发生次数最频繁的开始。为了鼓励团队成员就这一话题展开交流，Scrum Master决定将这张Pareto表格贴在Scrum公告板与bug数量的旁边，并且每天对其进行更新。在每天早上的站立会议上，团队都会报告当前的bug情况，而新产生的bug都会按照其分类添加到该表格中。这种方式能够使团队更明显地意识到每日质量性能的变化情况，同时也是实现PDCA中的C——Check（检验）的一种良好方式。当问题被根除之后，这方面的bug应该至少在一周之内不复存在了。不过，某些时候还是会发生这些bug，而这也是需要学习的地方。
　　举一个例子，该团队已经认识到了bug类别中有一种属于回归缺陷，即对软件的改动破坏了原本能够正常工作的特性。这种bug多数情况下发生在图形用户界面端，因为对这一部分进行自动化测试是非常困难的事。我们所找出的一个根本问题在于，初级程序员并不总是完全理解他们对代码的改动可能会造成的影响。对此问题的解决措施是在流程中加入一个新的步骤，在提交代码之前先让某个更资深的开发者进行代码复审。这一步骤大概只需要15分钟，但能够大幅降低回归缺陷出现的次数。此外还将对每次发布的bug数量进行每日评估（每天发布两次）。这种方式还能够提高初级开发者的技能水平。
　　最终，所有的问题都得到了解决，结果是令人惊叹的：所有的问题都通过标准流程（在提交代码之前进行代码复审）得以一一根除。每日的bug数量直线下降，每个迭代周末能够提交的包括完整功能并且无bug的用户故事数量也在上升。3个月之后，该团队就从之前产生bug数量最多的困境中摇身一变，成为了整个项目中高质量、高效率团队的代名词。
　　这种方式相比之前的方法显得更为精益。因为它对每日绩效（质量）和生产力（提交的用户故事数量）产生了直接的影响，并且为团队带来了新的操作标准。
　　查找和修复 bug
　　

　　1. 明确目的。仔细查阅异常报告，确定是否是个 bug，找出各种有用的信息发现问题的症结，予以重现。再次检查是否与报告发生重复。如果发生重复，那看看曾经的相关人员是如何处理的。
　　2. 准备工作——找出正确的代码，用排除法清理工作区域。
　　3. 匹配测试环境。如果客户正在操作计算机配置，那么此过程可以跳跃。
　　4. 明确代码的用途，确保现有测试工具一切正常。
　　5. 好了，现在可以出发钓鱼去咯——重现和诊断错误。如果你不能做到重现，那你就不能证明你已经完成修复工作。
　　6. 编写测试案例，或者通过现成的测试案例来捕获 bug。
　　7. 进入修复模式——请务必确保不会影响到其他任何部分。但是，在开展修复工作之前，可能你还要包揽重构工作，因为只有这样，你才能无所顾忌地捣鼓代码。而且事后回归测试，还能确保你不会加入任何新的 bug。
　　8. 整理代码。通过一步一步重构，让你的代码更易于理解，更安全。
　　9. 找别人来审查一下，当局者迷旁观者清。
　　10. 再次检查此修复过程。
　　11. 试着不从主线出发，以检查这些 bug 是否会影响其他支线。合并这些变化，处理代码中的差异，回顾所有的审查和测试等工作。
　　12. 思考。好好想一想哪里错了以及为什么错了？为什么你的修复会起效？这种类型的 bug 还会出现在哪里？如果一个 bug 需要耗费你很多时间，那么一定要好好弄清楚原因。此外，还需要思考的是，怎么做才能吸取经验教训，将来在类似的问题上不再栽跟头？以及，我们采用的方法、使用的工具是否还有可以改进的地方？以及这些 bug 的影响和严重程度。
　　找到 bug，还是修复 bug，哪个需要更多时间？
　　或许建立一个测试环境、重现问题和测试 bug 所需的时间，要远远多于找到 bug 和修复 bug 的时间。不过对于一小部分显而易见的 bug，找到它们很简单——不过修复起来可能就不尽如人意了。
　　大部分的软件漏洞的来源在哪里？分析师认为，相较于修复，发现 bug（包括理解 bug 和重现 bug）所需时间更长。有研究表明，大多数的 bug（差不多有3/4）既易于发现又易于修复：5天或许更少（这是基于大规模实时系统通过重量级 SDLC、大量审查和测试得出的数据）。但是也有很恶心的bug，即便你可以轻轻松松揪到它，还是还得“呕心沥血”才能修复好。
　　所以如果你打赌说你能很快修复bug，大多数情况下你还真没说错。不过当你打赌输了的时候，那么，嘿嘿，就意味着你有烦恼了。所以，下次，boss再问什么时候能修复bug，别再傻乎乎地回答“马上就能搞定”了。
　　今天的分享就到这了，也不知道对大家有用不，如果有用的话，那就点个赞吧！如果哪部分知识点欠缺，欢迎各位朋友进行补充哦~更多精彩的内容，就在编程学习网教育，还不赶紧行动？等着你们哟~