人工少女人物补丁安装方法 人工三人物mod
脸书开发了一款名为Getafix的工具，可以自动找出bug修复方案，提供给工程师审批，大大提高了工程师的工作效率和整体代码质量。Getafix不仅可以为工程师提供直观的修复方案，还可以使用更强大的聚类算法来分析问题代码的上下文，以找到更合适的修复方案。Getafix是第一个大规模部署在脸书生产环境中的自动修复工具，它进一步提高了拥有数十亿用户的脸书应用程序的稳定性和性能。
现代生产环境代码库非常复杂，并且不断更新。为了创建一个可以自动找到bug修复的系统——不需要工程师的帮助——我们构建了一个工具，它可以从工程师之前对代码库的更改中学习如何修复bug。它发现一些隐藏的模式，并使用它们来确定最有可能修复新错误的补救措施。
这个名为Getafix的工具已经部署在脸书的生产环境中，进一步提高了数十亿人使用的应用程序的稳定性。Getafix通常与其他两个脸书工具结合使用，但这项技术也可以用于其他地方。目前可以提供修复Infer发现的bug的建议，Infer是我们的静态分析工具，可以识别Android和Ja代码中的空指针异常。它还通过SapFix为我们的智能自动化测试系统Sapienz检测到的bug提供修复建议。现在，我们将了解更多关于Getafix如何学习修复bug(指任何代码问题，不仅仅是导致应用崩溃的问题)。
Getafix的目标是让计算机处理日常工作，但是是在人类的监督下，因为一个bug是否需要复杂的修复仍然需要由人类来决定。该工具将一种新的层次聚类方法应用于数千个以前的代码更改，并检查代码更改本身及其上下文。它可以检测到bug的基本模式，并提供以前的自动修复工具无法检测到的修复方案。
Getafix还可以显著减少bug修复过程中可能需要更改的具体空，从而更快速地选择合适的修复手段；此外，它不再像过去的暴力破解和基于逻辑的技术那样对计算时间要求苛刻。这种更高效的方法使Getafix能够成功部署到生产环境中。同时，由于Getafix可以从过去的代码更改中学习，因此足以产生人类工程师更容易理解的修复结论。
Getafix已经部署在脸书生产环境中，负责自动修复Infer report提供的null dereference bug，还可以针对Sapienz标记的null dereference相关的崩溃错误提供修复建议。此外，Getafix还用于解决新版本Infer重新访问现有代码时发现的代码质量问题。
Getafix 与传统简单自动修复工具有何不同
在目前的行业实践中，自动修复功能主要用于各种基础问题，而代码修复更简单。例如，分析器可能会发出一个“致命异常”警告，强调开发人员可能忘记在新的异常(…)前添加一个抛出。自动修复工具可以直接完成调整，具体的调整方式可以通过lint规则来定义——换句话说，它不需要知道操作应用的具体情况。
而Getafix则完全不同。它提供了更一般的功能，可以结合上下文相关的因素来解决问题。在下面的代码示例中，对应于第22行中的推断错误，Getafix给出了以下修复结论:
需要注意的是，这种修复方法不仅依赖于变量ctx，还依赖于方法的返回类型。与简单的lint修复不同，这种修复不能合并到Infer本身中。
下图是Getafix为Infer bug提供的修复方法；虽然来自Infer的bug总是一样的(null方法调用，可能导致NullPointerException的风险)，但是每个特定的修复操作仍然是唯一的。另外需要强调的是，Getafix的修复方式与人类开发者的常见操作完全一致。
深入了解 Getafix 关键技术细节
Getafix的组织形式如下图工具链所示。在本节中，我们将描述Getafix的三个主要组件及其各自的功能和挑战。
Tree Differencer 标识树级别的更改
基于抽象语法树的差分器负责识别两个源文件之间的实际编辑痕迹，例如同一文件的连续修订。例如，它将以如下粒度检测编辑:用if打包语句，添加@Nullableannotation或import，预先将条件返回到现有方法，等等。在下面的例子中，插入条件判断语句if dog为null并提前返回，将public重命名为private，移动方法都会被检测为实际编辑。基于行的差异工具只会将方法标记为完全移除和插入，树差异器可以检测到这种移动，并将移动方法中的插入操作视为实际差异。
Tree Differencer的主要挑战是如何有效准确地对齐树级中的“之前”和“之后”部分，从而识别正确的实际编辑及其映射关系。
新的修复模式挖掘方法
Getafix使用新的层次聚类技术和反集成方法(即一种可以在不同符号表达式之间进行归纳的现有方法)来挖掘模式。之后，它会建立一组可能相关的树差异，然后选择集合中最常见的程序，切换到修复模式。这些模式可能是抽象的，包含程序转换的不同“漏洞”。
以下示例图像显示了一组分层结构，即由一组编辑生成的树形图。(本例中，我们直接采用上例中的编辑结果。每一行都显示了一种编辑模式——其中紫色代表“之前”，蓝色代表“之后”——以及一些元数据。每个垂直黑条对应于层次中的特定级别，其中黑条顶部的编辑模式表示通过反转结构中同一级别的所有其他编辑获得的模式。其他编辑由细黑线连接。反集成将前一个例子中的“如果狗为null，则提前返回”的条件与另一个编辑器结合起来——后者的唯一区别是“狗在喝水”。因此，它会生成一个抽象的修复模式，代表共性。反整合引入的符号h0代表了一个可以基于上下文实例化的“漏洞”。
接下来，编辑模式可以与其他具有更多变量名但总体结构不变的编辑模式相结合。当根据树上下文进行梳理时，整个过程会产生越来越抽象的编辑模式。例如，它可以将这种编辑与与猫相关的编辑结合起来，从而在图表的上部位置获得一种抽象的编辑。
更重要的是，这种层次化的匹配过程为Getafix提供了一个强大的框架，足以在代码变更中找到各种可重用的模式。如下图所示，我们的代码库中总共有2288个用于修复Infer报告的空指针错误的编辑被总结成一组树形图(水平布局，小型化)。我们希望挖掘的修复模式无疑就隐藏在这个树形图中。
基于反集成方法的模式挖掘并不是什么新鲜事，但是为了用尽可能少的修复操作解决新的bug，我们需要进一步强化挖掘得到的模式结果。
其中一个变化就是引入了一部分周围的代码，也就是编辑结果没有变化的部分。这样，我们不仅可以找到人们在变化中采用的模式，还可以在应用变化时找到上下文中的一些模式。例如，在上面的第一个树形图中，我们注意到dog.drink(…)中有两个不同的编辑器；添加if(dog==null)return before。虽然dog . drink(…)；没有什么变化，但是应该认为是模式的“之前”和“之后”部分的上下文信息，从而帮助我们理解这个修复的应用场景。从更高的编辑层面来说，dog.drink()的上下文与其他上下文合并形成抽象上下文h0.h1()，用来限定模式的适用位置。在下一节中，我们将介绍另一个更实际的例子。
根据以往自动修复工具的文献，贪婪聚类算法往往不太可能学习到上述情况。这是因为贪婪聚类算法倾向于保持每个聚类的单一表示，因此如果在训练数据的所有编辑中不存在上下文，则该算法不会引入上下文。例如，如果编辑将在do(list.get())中进行；插入if(列表！= null)返回，那么贪婪聚类算法会提前丢弃所有关于返回到特定插入位置的上下文。相反，Getafix的层次聚类方法尽可能地保留了各级的上下文，从而保证了整体结构的通用性。从某种程度上来说，虽然我们想要学习的一些一般语境可能会丢失，但它们仍然会存在于结构中的一些底层位置。
除了周围的代码，我们还将编辑与提示这些编辑的Infer bug报告关联起来，从而了解编辑模式与对应的bug报告之间的映射关系。在上面第一个树形图中，我们可以看到Infer在bug报告中将“errorVar”作为bug源变量，给出了反统一后的漏洞h0。在此基础上，我们再将发布新的Infer bug报告时需要注意的变量改为h0，从而使整个修复模式更加具体。
Getafix 如何创建补丁
最后一步，我们需要考虑如何获取有bug的源代码，从挖掘出的结论中生成修复模式，从而为源代码生成修复补丁。对此，我们往往有多种修复模式可供选择(如上图树形图所示)。因此，下一个挑战是如何选择正确的模式来修复特定的bug。如果模式适用于多个位置，Getafix还需要选择正确的匹配项。下面的例子说明了我们采用的一般方法，以及如何在Getafix中解决这个挑战。
例1:考虑我们之前挖掘过的模式:h0 . h1()；→ if (h0 == null)返回；h0 . h1()；
接下来简单介绍一下如何为完全陌生的代码生成以下补丁。
Getafix通过以下步骤创建修补程序:
1.找到子ast: mlistview。匹配“before”部分的clear listeners()；
2.实例化漏洞h0和h1。
3.用实例化的零件替换子零件。
请注意后面部分的h0是绑定的，因为它包含了未修改的上下文h0 . h1()；这将有助于限制应用该模式的位置数量。如果不修改上下文，则模式为→if(h0 = = null)return；。显然，这个模型将适用于许多与期望无关的位置，如mlistview . clear listeners()；之后甚至mListView = null之后。
其实只是插入模式也可能出现在树中一些更高的位置，其中有h0 . h1()；该上下文的模式已由负责在不同语句前插入return的模式完成。下面的例子展示了Getafix如何处理这种模式应用太广的情况。
例2:请考虑以下模式:h0.h1() → h0！= null & amp& amph0.h1()
通常这个补丁应该来自于if条件或者返回表达式的修复模式，所以我们当然希望它可以应用于这类上下文。但也适用于其他情况，比如上面例子中提到的call语句:mlistview . clear listeners()；。Getafix的排序策略会尝试估计模式的修复效率，并为其分配最有可能达到修复效果的上下文。这种策略使得系统在后续操作中不再依赖于验证步骤，从而大大减少了计算时间。
以上模式会和其他模式竞争，比如更具体的if (h0.h1()) {…} → if (h0！= null & amp& ampH0.h1 ()) {…}或者例1中只适用于调用语句而不适用于表达式的模式。由于更具体的模式往往具有更少的匹配位置，Getafix会将其视为更适合当前情况的解决方案，并为其分配更高的排名。
Getafix 实际应用与表现
Getafix已经部署在脸书的生产环境中，负责为Infer报告的null解引用bug提供自动修复建议。对了，Infer是我们的统计分析工具之一，负责为Sapienz发现的与null dereference相关的崩溃bug提供修复建议。此外，Getafix还负责解决Infer过去提出的一些重要bug。
在一次实验中，我们将Getafix计算出的修复建议与之前的人工修复方法进行了对比。我们发现，在包含大约200个小编辑的数据集中，修复由Infer null方法调用的各种错误时，需要修改的代码不到5行。此外，在大约四分之一的情况下，Getafix提出的排名最高的补丁与手动创建的补丁完全匹配。
在另一个实验中，我们专注于Instagram代码库的一个子集，并尝试批量修复大约2000个null方法调用。Getafix可以在大约60%的bug中尝试使用补丁，90%的尝试都通过了自动验证——这意味着它可以被编译，Infer不会再发出警告。总的来说，Getafix成功地自动修复了1077个空方法调用错误(大约53%)。
除了对新的INFER bug提供修复建议，我们还用同样的方法清理原代码评审中积累的旧INFER bug。我们清理了上百个不能返回空的INFERBUGs和不能空的字段。有趣的是，这项工作完成后，Getafix在自动修复建议中，越来越擅长处理return空和fields 空的问题，两者的修复成功率分别从56%和51%提高到62%和59%。总的来说，在过去的三个月里，Getafix提供的一系列建议已经帮助我们成功修复了数百个额外的bug。
Getafix还为SapFix生成修复建议，以处理Sapienz检测到的崩溃。在过去的几个月里，SapFix使用的修复方法中，大约有一半来自Getafix，并且实际上是有效的(所有测试都通过了)。Getafix向SapFix提供的所有修复建议中，约有80%通过了所有测试。
提升 Getafix 影响力
Getafix帮助我们实现了让计算机处理日常bug修复工作的重要目标。随着我们自己的测试和验证工具的不断完善，预计未来Getafix将能够更好地防止各种部署后故障。
我们还注意到，Getafix挖掘的修复模式不仅仅是为了回应Infer报告的bug事实上，它还可以针对人工代码检查结果给出修复建议。这个额外的修复模式资源将为自动代码审查带来令人兴奋的可能性。换句话说，未来我们可能会把代码库中已经被多次标记和修复的bug直接交给自动化工具进行处理，而不需要任何人工筛选。
Getafix是我们构建大型代码语料库和对相关元数据进行统计分析的智能工具的整体计划的一部分。这类工具的出现有望改善软件开发生命周期的方方面面，包括代码发现、代码质量和执行效率。我们从Getafix中获得的宝贵见解也将帮助我们在该领域构建和部署更多类似的重要工具。
原始链接:
https://code . FB . com/developer-tools/geta fix-how-Facebook-tools-learn-to-fix-bugs-自动/
