微网站开发素材购买域名做销售网站可以吗

1. 引言

研究背景：现代生产代码库极其复杂并且不断更新。静态分析器可以帮助开发人员发现代码中的潜在问题（在本文的其余部分中称为错误），这对于在这些大型代码库中保持高代码质量是必要的。虽然通过静态分析尽早发现错误是有帮助的，但修复这些错误的问题在实践中仍然主要是手动任务，阻碍了静态分析工具的采用。

现存问题：大多数静态分析器都会查找常见错误类别的实例，例如潜在的空取消引用、流行 API 的错误使用或特定语言结构的误用。研究团队观察到，针对特定错误类别的修复通常彼此相似：它们有一个模式。也就是说，过去人类对同一错误类别的修复可能会提供有关如何修复该错误类别的未来实例的见解。鉴于这一观察，是否可以通过学习过去的修复来自动修复发现的错误？

研究内容：论文通过学习过去的修复来解决自动修复常见错误类别实例的问题。论文假设两个输入：（1）修复特定类型错误的一组更改，例如来自代码库的版本历史记录。这些变化可以作为训练数据来学习修复模式。(2) 一段带有我们要修复的静态分析警告的代码。仅给出这两个输入，问题是预测解决方案，以类似于或等于人类开发人员所做的方式解决静态分析警告。通过自动生成修复程序并仅将是否应用修复程序的最终决定留给人类，可以大大减少解决静态分析器指出的错误所花费的总体工作量。

论文专注于那些具有不平凡但重复性修复的错误。一方面，有些错误类别通常意味着特定的修复。例如，对于建议某个字段为最终结果的警告，实施自动修复建议非常简单。这种自动修复可以由该规则的作者在静态分析器中定义，而不需要知道应用该规则的特定上下文；事实上，有些容易出错规则带有自动修复功能。另一方面，一些错误需要复杂的、特定于应用程序的修复，例如用户进行一系列特定交互后 UI 选项卡不显示的问题。在这里，论文的目标是介于这两个极端之间的错误类别，其中找到修复程序并非易事，但典型的修复程序属于一组重复出现的修复模式。对于此类错误类别，通常存在不止一种方法来解决问题，并且解决错误类别的特定实例的正确方法取决于上下文，例如，静态分析警告周围的代码。

作为本工作中针对的错误类别的一个示例，请考虑 NullPointerExceptions 仍然是 Java 和其他语言中最普遍的错误之一。如果静态分析器警告潜在的空取消引用，开发人员可以通过各种方式解决该问题。上图显示了空取消引用错误修复的三个匿名示例，这些示例分别向现有 if 条件添加了一个连接、用三元运算替换了调用以及添加了提前返回。虽然所有这些修复都引入了某种空检查，但确切的修复在很大程度上取决于现有的代码。除了这些示例之外，还有更多方法可以修复空取消引用错误，例如，通过添加新的 if 语句或以分离方式扩展现有的 if 条件。学习所有这些修复模式并决定将哪一种模式应用于给定的错误代码是一个不小的问题。论文的工作旨在自动修复大规模工业软件开发中的错误。 这种设置会带来一些有趣的挑战：

• 为了减少修复错误所花费的人力时间，该方法可能只提出少量潜在的修复方案，最好只提出一个修复方案。
• 为了使此修复为开发人员所接受，建议的修复应该类似于人类：与人类开发人员将实现的修复非常相似或完全相同。