使用 安全修复损坏的版本

ditikhatun12

自动修复非建筑代码可以提高整体任务完成情况的生产率，并且只要采用高质量的培训数据和负责任的监控，似乎不会对代码安全产生可检测到的负面影响。 软件开发是设计、编写、构建、测试、部署和调试的循环过程。如果您曾经解决过一个构建错误，结果又引入了个错误，那么您就会熟悉在不熟悉的代码中寻找类型不匹配的挫败感，或者使用一些新的  诊断出错的地方。 在 每次保存源代码文件时，代码的快照都会保存到版本控制中。每次构建运行时，都会保存构建日志。这是一个数据宝库！我们可以确定构建何时中断、出现哪些错误消息、构建何时成功以及更改了哪些代码 - 本质上是开发人员如何修复构建。 今天，我们描述如何训练模型来预测构建修复。正如我们之前讨论的，是一种使用整个软件开发过程作为训练数据的方法。使用这个专用的构建修复 模型，我们随后在IDE中显示修复，并对此功能进行了受控实验。该实验显示了多种生产力指标在统计​​上的显着收益，包括代码更改数量增加了。

这些收益不仅本身有好处，而且还通过自动化消除了开发人员的辛苦工作，让开发人员有更多时间创造性地解决问题。这可以通过消除障碍来促进注意力集中，从而使开  垃圾邮件号码数据 发人员保持更长时间的心流状态。事实上，我们现在观察到，大约 34% 在指定月份遇到构建损坏的用户最终应用了此类 ML 建议的修复。当应用机器学习生成的修复程序时，我们还没有发现安全风险或错误有明显增加。现在，所有开发人员都可以使用 ML 驱动的构建修复，并且最近在上得到了重点介绍。 正在训练的构建修复模型的概述以及对代码的修复建议。预先训练的模型根据开发人员的构建错误及其修复的记录进行微调。然后，该模型用于在 IDE 中实时建议修复开发人员的构建。 问题和动机 我们的雄心源自于改善开发人员修复Java构建错误的体验的愿望。我们能否使错误消息更具可操作性，甚至自动修复错误？我们利用对其开发人员代码的全面记录和的研究专业知识，通过 ML修复 损坏的构建 。




构建错误并不都是简单的缺少括号、拼写错误或哎呀我又忘记了我的依赖项。来自泛型或模板的错误可能会很复杂，并且错误消息可能很神秘。在 ，构建不仅仅是编译。多年来，人们做出了许多努力来“左移”开发生命周期中可能发生的几种类型的错误，尽早检测它们，经常在构建时（即，当代码处于早期阶段时）检测到它们。正在编写的阶段）。例如，在每个构建上都会运行一组精选的容易出错的 静态分析检查器。构建错误和一些静态分析检查会阻止代码更改的提交。我们看到了解决这些更复杂问题的方法的潜力，因此我们将修复范围扩大到其他类型的错误，然后扩展到包括在内的其他语言，以及更多环境。 训练和输入数据 为了从 的发展历史中生成训练数据，我们组装了“解决方案会议”。这些是在同一工作区中发生的代码快照和构建日志的时间顺序，捕获从第一次发生损坏到解决问题的代码更改。同一工作区中随着时间的推移发生的一系列四个构建中的两个解决会话的细分。