基于反合一方法的模式挖掘并非什么新鲜事物，但要想以尽可能少的修复操作解决新 bug，我们还需要对挖掘得出的模式结果做进一步强化。

其中的变化之一就是引入一部分周边代码，即编辑结果当中没有变更的部分。如此一来，我们不仅能够发现人们在变更中采取的模式，同时也能发现应用变更时上下文中存在的某些模式。举例来说，在上面的第一份树状图中，我们注意到有两项不同的编辑会在 dog.drink(…); 之前添加 if(dog==null)return。尽管 dog.drink(…); 没有变更，但其应被作为模式“之前”与“之后”部分的上下文信息进行考量，从而帮助我们理解这项修复的应用情景。从更高的编辑层级上考虑，dog.drink() 这一上下文与其它上下文合并成为了抽象的上下文 h0.h1()，用以限制模式的适用位置。在下一节中，我们将介绍另一个更具现实意义的示例。

根据以往的自动修复工具文献所述，贪婪聚类算法往往不太可能学习到上述情况。这是因为贪婪聚类算法倾向于维持各个聚类的单一表示，因此如果上下文不存在于训练数据的全部编辑当中，则该算法将不会引入该上下文。例如，如果某项编辑会在 do(list.get()); 与以上示例中提到的 dog.drink() 合并时插入 if (list != null) return，那么贪婪聚类算法会丢弃全部关于提前返回具体插入位置的上下文。与此相反，Getafix 的分层聚类方法则尽可能在各层级上保留上下文，从而确保整体结构的通用性水平。在某种程度上讲，虽然我们希望学习的某些常规上下文可能丢失，但其仍将存在于结构当中的某些底层位置。

除了周边代码之外，我们还将编辑与提示这些编辑的 Infer bug 报告关联起来，从而了解编辑模式与对应的 bug 报告之间的映射关系。在前文第一份树状图中，可以看到 Infer 在 bug 报告中将“errorVar”视为 bug 来源变量，并在进行反合一之后给出漏洞 h0。以此为基础，我们接下来即可在发布新的 Infer bug 报告时将需要关注的变量修改为 h0，从而使得整个修复模式更为具体。

最后一步，我们需要考虑如何获取存在 bug 的源代码并从挖掘到的结论中生成修复模式，从而针对源代码生成修复补丁。在这方面，我们往往拥有多种修复模式可以选择（如前文树状图所示）。因此，接下来的挑战就是如何选择正确的模式以修复特定 bug。如果该模式适用于多个位置，Getafix 还需要选择出正确的匹配项目。以下示例说明了我们采用的常规方法以及如何在 Getafix 当中切实解决这项挑战。

示例 1：考虑我们之前挖掘到的模式: h0.h1(); → if (h0 == null) return; h0.h1();

下面，我们将简要介绍如何为完全陌生的代码生成以下补丁。

Getafix 通过以下步骤创建补丁：

1. 找到与“之前”部分匹配的 sub-AST: mListView.clearListeners();

2. 对漏洞 h0 与 h1 进行实例化

3. 利用实例化之后的部分替换 sub-AST

请注意，之后部分中的 h0 是绑定的，因为其中包含了未修改的上下文 h0.h1();，这将有助于限制模式适用的位置数量。如果不修改上下文，则该模式将为 → if (h0 == null) return;。很明显，这种模式将适用于众多与预期无关的位置，例如 mListView.clearListeners(); 之后、甚至是 mListView = null; 之后。

实际上，仅插入模式也有可能出现在树状图中的某些较高位置，其中具有 h0.h1(); 这一上下文的模式已经通过负责向另一不同语句之前插入 return 的模式完成了反合一。以下示例说明了 Getafix 如何处理这类模式适用范围过广的情况。

示例 2：请考虑以下模式: h0.h1() → h0!=null && h0.h1()

通常情况下，此补丁应该来自对 if 条件或者 return 表达式的修复模式，因此我们当然希望其适用于这类上下文。但其同时也适用于其它一些情况，例如以上示例当中提到的调用语句：mListView.clearListeners();。Getafix 的排名策略会尝试对模式的修复效能做出估算，并为其分配最可能实现修复效果的上下文。这项策略使得该系统能够在之后的运行当中不再依赖于验证步骤，从而显著降低计算时间。

以上模式将与其它模式竞争，例如更为具体的 if (h0.h1()) { … } → if (h0!=null && h0.h1()) { … }或者示例 1 中仅适用于调用语句而非表达式的模式。由于具体程度更高的模式往往拥有更少的匹配位置数量，因此 Getafix 会将其视为更适合当前情况的解决方案并为其分配更高的排名。

Getafix 现已部署在 Facebook 的生产环境中，负责为 Infer 报告的 null 解引用 bug 提供自动修复建议。顺带一提，Infer 是我们的一款统计分析工具，负责为 Sapienz 发现的、与 null 解引用相关的崩溃 bug 提供修复建议。此外，Getafix 还负责解决 Infer 以往提出的某些重要 bug。

在一次实验当中，我们将 Getafix 计算出的修复建议与以往人工编写的修复方法进行了比较，我们发现，在对大约包含 200 项小型编辑的数据集内各种 Infer null 方法调用 bug 进行修复时，需要修改的内容不足 5 行。此外，在大约四分之一的案例当中，Getafix 提出的排名最高修复补丁与人工创建的补丁完全匹配。

在另一项实验中，我们着眼于 Instagram 代码库中的一套子集，并尝试批量修复其中存在的约 2000 个 null 方法调用问题。Getafix 能够在大约六成 bug 中尝试使用某个补丁，且其中 90% 的尝试都通过了自动验证——这意味着其可编译且 Infer 将不再发出警告。总体来讲，Getafix 成功以自动方式修复了 1077 条（占比约 53%）的 null 方法调用错误。

除了针对新 Infer bug 提供修复建议之外，我们还利用相同的方式清理在原先代码审查中积压的旧有 Infer bug。我们已经清理了数百个返回不可为空的 Infer bug 以及字段不可为空的 Infer bug。有趣的是，在这项工作完成之后，Getafix 在自动修复建议中开始越来越擅长处理返回不可为空以及字段不可为空类问题，二者的成功修复占比分别由 56% 与 51% 增长至 62% 与 59%。总体而言，在过去三个月中，Getafix 提供的一系列建议帮助我们成功修复了数百项额外 bug。

Getafix 还为 SapFix 生成了修复建议，用以处理 Sapienz 检测到的崩溃问题。过去几个月以来，SapFix 所采用的修复方法中有约半数来自 Getafix 且实际有效（通过全部测试）。而在 Getafix 提供给 SapFix 的全部修复建议中，约 80% 通过了全部测试。

Getafix 帮助我们实现了让计算机处理常规 bug 修复工作这一重大目标。随着我们对自身测试及验证工具的不断完善，预计 Getafix 将能够在未来更好地防止各类部署后故障问题。

我们还注意到，Getafix 所挖掘出的修复模式不仅仅是在响应 Infer 报告的 bug; 实际上，其同时也能够针对手动代码检查结果给出修复建议。这种额外的修复模式源将给自动重复代码审查带来令人兴奋的可能性。换句话说，未来我们有可能会将代码库中曾被多次标记及修复的 bug 直接交给自动化工具处理，而不再需要任何人工筛查。

Getafix 是我们构建大型代码语料库以及相关元数据统计分析智能化工具这一整体性举措中的组成部分。此类工具的出现，有望改善软件开发生命周期中的各个层面，包括代码发现、代码质量与执行效率等等。我们从 Getafix 当中获得的宝贵见解，也将帮助我们在这一领域构建并部署更多其它与之类似的重要工具。

原文链接：

https://code.fb.com/developer-tools/getafix-how-facebook-tools-learn-to-fix-bugs-automatically/