缺陷分析做得好，写的bug就少。阿里巴巴资深技术专家与您分享如何进行高质量的缺陷分析，总结5大要点，通过缺陷分析消除开发中的各种盲点，打造学习型团队。软件开发中的缺陷意味着极高的价值，但许多组织只是承受缺陷的成本和后果，却让价值溜走。缺陷的价值在于它触发的学习和成长机会。把握缺陷带来的学习机会，可以快速提升组织的能力，未来缺陷更少，成本更低，更容易成功。但同时，有效的缺陷分析和跟踪行动需要有效的方法和相应的组织支持。缺陷意味着极高的价值最近我们举办了一次关于缺陷分析的研讨会。“有缺陷是好事吗？”我在工作坊开始时询问了参与的学生。“当然是坏事。”“不管是好事还是坏事，它就在那里。我不认为这是好事，这是正常的事情。”“这话好像没错，不过瑕疵很麻烦，而且我不喜欢瑕疵。”是的，没有人喜欢缺陷，它消耗研发成本，影响开发周期，但同时，缺陷与软件开发如影随形，无论有多少，它总是存在的。这是为什么呢？看图下图：软件开发是一个消除不确定性的过程软件开发与工业生产完全不同，工业生产可以通过消除过程中的各种可变性来逐步接近零缺陷的目标，因此六西格码法在工业生产中非常有效。软件开发的过程恰恰相反，每一次开发都是不确定的，我们往往是在项目接近尾声时才清楚整个项目的各种问题和细节，在这种假设下，不是追求零缺陷，而是倒不如说我们应该追求降低缺陷的影响，比如在缺陷产生的第一时间发现缺陷（射出时间甚至射出前）——因为此时的缺陷成本几乎为零，可以等同于“零缺陷”。如果说工业生产中的六西格玛方法来自于生产系统的创建，那么，在软件开发中，“零缺陷”对应的系统又是什么呢？它当然包括软件开发的过程和工具，但在我看来，最重要的应该是构建软件的核心主体——人。通过缺陷分析不断学习可以避免浪费缺陷成本。为什么会反复踩坑？许多团队的原因分析存在缺陷。曾经仔细分析过一个团队的缺陷原因分析，发现缺陷原因的高频词如下：编码有问题，下次写代码的时候多想想。代码审查没有做好。下一次代码审查应该是完整的。业务场景分析的不全面，下次分析的更全面。...相信写出以上原因分析的同学内心一定是很真诚的，也确实觉得自己当时的代码写的不够好，业务场景分析的不全面，代码审查不充分。然而，这种分析所产生的行动往往是无法实现的。是真的没有仔细考虑，还是只是出乎意料？这次复习不好，下次会好好做吗？这次场景分析不完整，怎么能更完整呢？这种原因分析过于宽泛以至于很难产生有效的改善措施，而且下次往往会落在同一个地方——看看之前的原因分析给出了多少类似的答案？每一次重复都是一次新的踩坑。还有一类原因分析，恰恰相反，过于具体，具体到没有学习价值的程度。比如这个在当时是设计错误的，服务A不应该调用服务B，服务A在调用服务B时要考虑到异常场景，等等。好了，现在缺陷已经修复，服务A调用服务B的异常场景已经固化在代码中了。下次如果是服务C调用服务D的异常场景怎么办？最合适的缺陷原因应基于此标准：这些原因需要产生系统的和可操作的结果。这个标准的测试方法是：如果下次出现某种场景，我们的应对方案是否有效？做好缺陷分析的5个关键点在实践中，我们总结了5个关键点，以最大限度地对缺陷进行学习分析。分别是：及时总结、设置卡点对分析、分组总结、负面清单支持的全分析、小组学习、及时总结机制建设、设置卡点”缺陷分析很重要，但研发同学也很重要忙，我们两个月做一次怎么样？”不要那么紧张——及时是最省钱的方法。为了让自己从忙碌中解脱出来，一次花15分钟做一次有效的缺陷分析，而且时间恰到好处。缺陷分析的最佳时间是当缺陷修复完成，这个时候记忆最新鲜，可以提早受益，如果一个缺陷已经过了两个月，缺陷分析的成本会变高，必须要有当时的原始记忆和上下文被取回，记忆准确与否，另当别论。怎样才能保证及时完成，从而保证这些重要但不紧急的事情发生呢？更有效的方法是在流程中设置卡点：当缺陷设置为已修复状态，或设置为关闭状态时，强制将缺陷分析设置为流程卡点，以便更好的驱动可以形成。结对分析，小组总结谁负责缺陷分析？是有具体缺陷的同学来做，还是召集整个团队一起做？召集整个团队进行缺陷分析有时成本太高。哪怕我们只分析线上比较晚的问题，哪怕每个缺陷只分析15分钟：100个缺陷，一个团队8个人，产品就是12000分钟，也就是200小时，这是一个惊人的数字，投入和产量不成正比。解决缺陷的学生确实最了解缺陷。但是，这样会不会形成“单点问题”，降低问题分析的有效性呢？我们的方案是：以pairanalysis为系统，让解决缺陷的同学做负责人，带一个小伙伴。结对不仅形成知识互补，在一定程度上消除了思维盲点，而且通过结对形成更深入的讨论，也提前对结果进行“验收”，提高分析质量。如有必要，成对的团体可以自由带入其他团体。团队定期讨论学习团队定期讨论重要的缺陷分析结果，这不仅是对团队结果的认可，也有利于团队成员之间形成传播，相互学习。负面清单支持的全面分析缺陷分析的目的是改进，所以重点是解决那些“未知的未知”问题。显然不是每个缺陷都应该深入分析。但是，如果我们定义是否应该针对每个缺陷进行分析，则会导致高决策成本和不可靠的质量。因此，我们的做法是在默认全额的基础上，使用负面清单进行过滤。对于负面清单中不存在的，进行缺陷分析。负面清单是团队层面的。每个团队都应该维护自己的列表，例如：已经在改进项中列出的偶发问题（不断扩充）这个东西有点类似于淘金。明确什么不该做，才能更高效地避免那些真正值得做的事情。湮。事实上，每次缺陷分析都会扩大负面清单的长度，需要进行缺陷分析的次数会越来越少，问题会更加聚焦，时间也会越来越节省。可操作的结果缺陷分析应该产生有价值的见解，足够的深度是关键。关于如何产生深度洞察，已经有很多成熟的方法，最典型的是5个为什么，也有著名的工具，比如鱼骨图。为了控制篇幅，本文省略了对这些方法的介绍，仅通过一个例子来说明我们如何在实际的缺陷分析中产生深入的洞察。一个缺陷描述了如下场景（示例适度抽象，不影响问题描述）：用户持有一个虚拟设备，该设备有一些附加资源。当用户删除设备时，应释放该设备的附加资源。但是发现在特殊场景下，这个附属资源并没有被释放。代码如下：voidreleaseResources(resoure_id){if(failedOfHardwareResourceRelease(resource_id)){writeLog("resourcereleasefailed");}}下面是关于问题的对话：“Whatisthereason?”“我们在需求分析阶段没有考虑到这种不成功发布的场景。”“OK。需求分析是问题所在，这是一个改进点。——但更重要的是：最终找到这个问题的最直接机会是什么？”“在写代码的时候。”“我们在写代码的时候有没有注意到这个问题？”“我们注意到了，所以我们写了日志，但是没有仔细考虑如何处理。这说明我们没有明确定义这段代码的职责。”“也许我们可以在编程规范中增加一项：当出现异常场景时，不仅要记录日志，还要和负责人明确场景和解决方案。以后，当只有写入错误日志，而没有其他处理时，我们会注意到这一点。”检验分析深度是否足够，最直接的指标就是产生的结果是否“可操作”，如果一个结果不可操作，往往意味着深度或抽象不够。建立起来并不总是那么容易，除了上述心智模式和运作方法，组织机制往往是成功的重点。我们总结了以下几点：做一个长期团队建立持续学习的心智模式组织的智力资产这些要点似乎是不言而喻的。但关于智力资产，我还是要多强调一点：分析的结果最终可能是流程改进、编程习惯和编程规范、代码审查的检查表、设计能力的提升、引入某些新的工程实践如实例化需求、等等。无外乎两种：短期动作，如实例化需求实践的引入、自动化测试机制的构建等。对于此类具体行动，明确责任人和结束日期，并与管理要求等工作项同级管理，确保其发生。长期规则是需要持续关注的事情，例如代码审查的常见问题列表，以及采用某些设计思想，例如合约设计、防御性编程等。对于这类问题，由于需要持续关注，它们需要作为团队资产的一部分进行维护。当然，如果技术上可行，应该尽快将其中一些做成工具，以减轻内存负担，提高可操作性。这个资产维护得越多，以后需要分析的缺陷就越少——当然，这也是所有资产的共性。总结现实是复杂的，统一的方法往往是不存在的。但是心智模型和某些规则和想法仍然存在。本文侧重于通过缺陷分析来学习。通过适当的方式，以可控的时间投入，为组织积累宝贵的财富，并在未来的发展中获得数倍、数十倍、甚至数百倍的回报。忙不是理由。如果您将来丢失了一个新的错误，您将把它赚回来。通过缺陷分析，我们可以形成以下输出：建立团队在需求分析、软件设计、编程、测试、运维等方面的共同思想形成共同问题检查表采用或开发新工具改进现有流程形成有针对性最重要的是针对具体问题的行动计划。通过消除各种盲点，我们的能力会更强，发展会更顺畅，我们会更接近零缺陷的目标。
