作者 | 嵩华导读：缺陷分析做得好，bug 写得少。阿里资深技术专家和你分享如何举行高质量的缺陷分析，总结了 5 个要点，通过缺陷分析消除开发中的种种盲点，打造一个学习型的团队。

软件开发中的缺陷隐含着极高的价值，可是许多组织都仅仅忍受了缺陷带来的成本和结果，却让价值白白溜掉了。缺陷的价值是其触发的学习和发展的时机。掌握缺陷带来的学习时机，可以快速提高组织的能力，未来的缺陷更少，成本更低，更容易乐成。但同时，有效的缺陷分析和跟踪行动需要有效的方法和相应的组织的支持。

缺陷隐含着极高的价值最近我们做了一次关于缺陷分析的事情坊。“发生缺陷是一件好事吗？” 在事情坊开始的时候，我这么问到场的同学。“那固然是一件坏事了。”“不管是不是好事，它就在那儿。

我以为无所谓好欠好，这是一件正常的事情。” “这么说似乎也对，可是缺陷很贫苦，我没法喜欢缺陷。”是的，没有人喜欢缺陷，它消耗研发成本，影响开发周期，但同时，缺陷又和软件开发如影随形，无论几多，始终都在。这是为什么呢？看下面的这张图：软件开发是消除不确定性的历程软件开发和工业生产完全差别。

工业生产通过消除历程中的种种可变性，能够逐步迫近零缺陷的目的。所以，六西格玛方法在工业生产中很是行之有效。软件开发的历程则恰恰相反。

每一次开发，都是不确定的，我们往往都是在项目邻近竣事的时候，对整个项目的种种问题和细节才变得清晰。在这种假设下，与其追求零缺陷，倒不如说是我们应该追求降低缺陷的影响，好比，在缺陷发生的第一时间（注入时间甚至注入之前）就发现缺陷——因为这时候缺陷的成本险些为零，这也就可以等价为“零缺陷”了吧。如果说工业生产中的六西格玛方法来自于对生产系统的打造，那么，在软件开发中，“零缺陷”对应的系统是什么呢？它固然包罗软件研发的流程和工具，可是，在我看来，最重要的，应该是打造软件的焦点主体——人。通过缺陷分析来连续学习，才气不浪费缺陷所消耗的成本。

为什么会重复踩坑有不少团队是有缺陷原因分析的。我曾经仔细分析过一个团队的缺陷原因分析，发现了下面这些缺陷原因的高频词：编码有问题，下次写代码的时候想的更仔细一些。代码评审做的欠好。

下次代码评审要充实。业务场景分析不全面，下次分析的更全面一些。......我相信，写下上述原因分析的同学，心田一定是很真诚的，也是真心以为自己其时代码写的不够好，业务场景分析的不全面，代码评审不够充实。可是，这个分析带来的行动，却往往是不行告竣的。

是真的想的不仔细吗，还是就是想不到？这次评审做的欠好，下次就肯定能做好了吗？这次场景分析不全，那么怎么才气更全呢?这种原因分析过于宽泛了，以至于很难发生实际有效的革新行动，下次往往还是会在同样的地方跌倒——大家只要看一下在既往的原因分析中，有几多次类似的谜底？每一次重复，就是一次新的踩坑。另有一类原因分析，恰恰相反，又过于详细化了，详细化到了没有学习价值的层面上。例如，这是其时设计的差池，A 服务就不应挪用 B 服务，A 服务应该思量到B服务挪用中的异常场景，等等。

好吧，缺陷现在已经修复了，A 服务挪用 B 服务泛起的异常场景已经固化在代码中了，下一次如果是 C 服务挪用 D 服务的异常场景应该怎么办呢？最合适的缺陷原因应该基于这样的尺度：这些原因需要形成系统化的可行动的效果。这个尺度的磨练方式是：下一次如果发生某某场景，我们的应对方案是否有效?做好缺陷分析的 5 个要点在实践中，我们总结了 5 个要点，来最大化出于学习目的的缺陷分析的实践操作。它们是：实时总结，设置卡点结对分析，小组总结负面清单支持下的全量分析可操作的效果团体学习，机制建设实时总结，设置卡点“缺陷分析很重要，可是研发同学都太忙了，我们两个月集中做一次怎么样？”别那么紧张——实时才是最节约的方式。要从忙碌中解放出来，每次花 15 分钟，做一次有效的缺陷分析，时间已经妥妥的啦。

缺陷分析的最好时间是缺陷修复完成的时间。此时影象最新鲜、也能早收益。

如果一个缺陷已经由去了两个月，那么缺陷分析的成本就变高了，得找回原来的影象和其时的上下文，这个影象准确禁绝确还是另一回事。怎样才气保证实时地做，从而保证这些重要而不紧迫的事情发生呢？一个比力有效的方式，是设置流程中的卡点：当缺陷被设定为已修复状态、或者设定为已关闭状态时，强制把缺陷分析设定为一个流程卡点，这样就能形成比力好的驱动。结对分析，小组总结谁来卖力缺陷分析？是让详细这个缺陷的同学来做，还是召集整个团队一起？召集整个团队来做缺陷分析，有时候价格过于高昂。纵然仅仅分析比力后期的线上问题，纵然每个缺陷仅仅分析 15 分钟：100 个缺陷，每个团队 8 小我私家，乘积就是 12,000分钟，合 200 个小时，也是一个惊人的数字，投入产出不成比例。

解决缺陷的同学确实是对这个缺陷明白最好。可是，这会不会形成“单点问题”，降低问题分析的有效性？我们的方案是：1. 把结对分析作为制度让解决缺陷的同学担任卖力人，搭配上一个小同伴。结对既形成了知识方面的互补，一定水平上消除了思维盲点，也通过结对形成了更深入的讨论，也提前举行效果的“验收”，提高分析的质量。如果有须要，结对的小组可以自主决议是否引入其他人到场。

2. 团队定期讨论学习团队定期对重要的缺陷分析效果举行讨论，既是对小组结果的验收，更有利于在团队成员间形成流传，相互学习。负面清单支持下的全量分析缺陷分析的目的是提升，所以，重在解决那些“未知的未知”的问题。显然不是每个缺陷都应该深入分析。可是，如果我们针对每个缺陷都界说它该不应分析，又会导致决议成本过高，而且质量也不行靠。

所以，我们的做法是在默认全量的基础上，使用负面清单举行过滤。通常负面清单不存在的，都举行缺陷分析。负面清单是团队级此外。

每个团队都应该维护自己的列表，例如：偶发问题已经列在革新项中的问题（不停扩充）这个事情和淘金有些类似，明确不要什么，能更高效地制止那些真正值得做的事情不被淹没。事实上，每次缺陷分析都市扩充负面清单的长度，所需的缺陷分析数量将越来越少，问题越来越聚焦，时间也越来越节约。

可操作的效果缺陷分析应该发生有价值的洞见，足够的深度是重点。在如何发生深度洞见方面已经有很是多成熟的方法，最典型的是 5 Whys，此外另有鱼骨图等著名工具可用。

为了控制篇幅，本文略去对这些方法的先容，只通过一个实例来说明在实际的缺陷分析中，我们是如何发生深度洞见的。某缺陷形貌了如下的场景（该实例在不影响问题说明的情况下做了适度抽象）：用户持有某个虚拟设备，该设备有一些隶属资源，当用户删除设备时，该设备的隶属资源应该被释放。可是，发现在一种特殊场景下，这个隶属资源并没有获得释放。

代码如下：void releaseResources (resoure_id){ if (failedOfHardwareResourceRelease(resource_id)){ writeLog("resource release failed"); }}下面是关于这个问题的对话：“原因是什么？”“我们没有在需求分析阶段思量到这种释放不乐成的场景。”“OK。需求分析是问题，这是一个革新点。

——可是更重要的：最后发现这个问题的最直接的时机点是哪个时间点？”“写代码的时候。”“写代码的时候我们注意到这个问题了吗？”“注意到了啊，所以写了 log，可是没仔细想应该怎么处置惩罚。这说明我们对这段代码的职责界说不清晰。

”“也许我们可以在编程规范中加入一条：泛起异常场景时不应该只记载 log，而应该和卖力人澄清场景和处置惩罚方案。在未来，当泛起了仅仅泛起写错误 log，可是没有其他处置惩罚的时候，我们就能注意到这一点。”磨练分析深度是否足够，最直接的指标就是发生的效果是否是“可行动的”。

如果一个效果是不行行动的，往往意味着深度或者抽象不够。团体学习，机制建设学习型组织并不总是容易建设。除了上述心智模型和操作方法之外，组织机制往往是乐成的重点。我们总结了如下几点：是恒久存在的团队建设连续学习的心智模型连续维护和使用本组织的智力资产这几点似乎都毋需多言。

可是关于智力资产，还是要多强调一下：分析效果最后可能会是流程革新、编程习惯和编程规范、代码评审的检查单、设计能力的提升、引入某些新的工程实践如实例化需求等，不外乎有两类：1. 短期的行动例如引入实例化需求实践、 建设自动化测试机制等。对于这类详细行动，要界说责任人和竣事日期，而且把它们和治理需求等事情项同等治理起来，确保其发生。2. 恒久的规则这类是需要连续关注的工具，例如代码评审的常见问题列表、采取某种设计思想如契约式设计、防御式编程等。

对于这类问题，由于需要连续关注，需要维护它们，并把它们作为团队资产的一部门。固然了，如果技术上可行，还是要把其中的一部门尽早做成工具，淘汰影象肩负，提升可操作性。这种资产维护的越多，就会发现未来需要继续分析的缺陷越少——固然了，这也是一切资产的共性所在。

总结现实情况纷繁庞大，统一的方法往往并不存在。可是心智模型和一定的纪律、思路还是存在的。本文聚焦于通过缺陷分析举行学习。

通过适当的方法，它可以在可控的时间投入下，为组织积累名贵的财富，而且在未来的开发中获得数倍、数十倍上百倍的回报。忙碌不是理由，在未来少掉一个新 bug，就赚回来了。通过缺陷分析，我们可以形成如下的产出：建设团队关于需求分析、软件设计、编程、测试、运维等方面的配合心智形成常见问题的检查单接纳或者开发新的工具革新既有流程形成针对特定问题的行动计划最最重要的，通过消除种种盲点，我们的能力也就越来越强，开发也就越来越顺畅，距离零缺陷的目的，就越来越近了。

泉源：阿里云开发者社区。

本文来源：pg电子平台官网入口-www.audaciousmagazine.com