做者 | 嵩华编程
导读：缺陷分析作得好，bug 写得少。阿里资深技术专家和你分享如何进行高质量的缺陷分析，总结了 5 个要点，经过缺陷分析消除开发中的各类盲点，打造一个学习型的团队。less
软件开发中的缺陷隐含着极高的价值，可是许多组织都仅仅忍受了缺陷带来的成本和后果，却让价值白白溜掉了。运维
缺陷的价值是其触发的学习和成长的机会。把握缺陷带来的学习机会，能够快速提升组织的能力，将来的缺陷更少，成本更低，更容易成功。但同时，有效的缺陷分析和跟踪行动须要有效的方法和相应的组织的支持。微服务
缺陷隐含着极高的价值
最近咱们作了一次关于缺陷分析的工做坊。工具
“发生缺陷是一件好事吗？” 在工做坊开始的时候，我这么问参与的同窗。 “那固然是一件坏事了。” “无论是否是好事，它就在那儿。我以为无所谓好很差，这是一件正常的事情。” “这么说好像也对，可是缺陷很麻烦，我无法喜欢缺陷。”学习
是的，没有人喜欢缺陷，它消耗研发成本，影响开发周期，但同时，缺陷又和软件开发如影随形，不管多少，始终都在。这是为何呢？测试
看下面的这张图：编码
软件开发是消除不肯定性的过程设计
软件开发和工业生产彻底不一样。工业生产经过消除过程当中的各类可变性，可以逐步逼近零缺陷的目标。因此，六西格玛方法在工业生产中很是行之有效。3d
软件开发的过程则偏偏相反。每一次开发，都是不肯定的，咱们每每都是在项目临近结束的时候，对整个项目的各类问题和细节才变得清晰。在这种假设下，与其追求零缺陷，倒不如说是咱们应该追求下降缺陷的影响，好比，在缺陷产生的第一时间（注入时间甚至注入以前）就发现缺陷——由于这时候缺陷的成本几乎为零，这也就能够等价为“零缺陷”了吧。
若是说工业生产中的六西格玛方法来自于对生产系统的打造，那么，在软件开发中，“零缺陷”对应的系统是什么呢？它固然包含软件研发的流程和工具，可是，在我看来，最重要的，应该是打造软件的核心主体——人。经过缺陷分析来持续学习，才能不浪费缺陷所消耗的成本。
为何会重复踩坑
有很多团队是有缺陷缘由分析的。我曾经仔细分析过一个团队的缺陷缘由分析，发现了下面这些缺陷缘由的高频词：
- 编码有问题，下次写代码的时候想的更仔细一些。
- 代码评审作的很差。下次代码评审要充分。
- 业务场景分析不全面，下次分析的更全面一些。
- ......
我相信，写下上述缘由分析的同窗，心里必定是很真诚的，也是真心以为本身当时代码写的不够好，业务场景分析的不全面，代码评审不够充分。可是，这个分析带来的行动，却每每是不可达成的。是真的想的不仔细吗，仍是就是想不到？此次评审作的很差，下次就确定能作好了吗？此次场景分析不全，那么怎么才能更全呢?
这种缘由分析过于宽泛了，以致于很难产生实际有效的改进行动，下次每每仍是会在一样的地方跌倒——你们只要看一下在既往的缘由分析中，有多少次相似的答案？每一次重复，就是一次新的踩坑。
还有一类缘由分析，偏偏相反，又过于具体化了，具体化到了没有学习价值的层面上。例如，这是当时设计的不对，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，就赚回来了。
经过缺陷分析，咱们能够造成以下的产出：
- 创建团队关于需求分析、软件设计、编程、测试、运维等方面的共同心智
- 造成常见问题的检查单
- 采用或者开发新的工具
- 改进既有流程
- 造成针对特定问题的行动计划
最最重要的，经过消除各类盲点，咱们的能力也就愈来愈强，开发也就愈来愈顺畅，距离零缺陷的目标，就愈来愈近了。
“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的公众号。”