谷歌公开自家「AI+软件工程」框架DIDACT:数千名开发者内部测试,用了都说生产力高


谷歌公开自家「AI+软件工程」框架DIDACT:数千名开发者内部测试,用了都说生产力高

文章插图
新智元报道
编辑:LRS
【新智元导读】AI时代的软件开发流程是什么样的?
任何一个大型软件都不是一开始就构思完善的,而是通过开发人员的一次次改进、编辑、单元测试、修复构建错误、解决代码审查,再循环解决问题,直到满足上线需求后才能把代码合并到仓库中 。
控制整个过程的学问就叫做软件工程 。
软件工程并非一个独立的过程,而是由开发人员、代码审查员、错误报告员、软件架构师和各种开发工具(如编译器、单元测试、连接器、静态分析器)之间的交流组成 。
最近,google公布了自家的DIDACT(Dynamic Integrated Developer ACTivity,动态集成开发人员活动)框架,用AI技术增强软件工程,将软件开发的中间状态作为训练数据,辅助开发人员编写、修改代码,并实时了解软件开发的动态 。
谷歌公开自家「AI+软件工程」框架DIDACT:数千名开发者内部测试,用了都说生产力高

文章插图
DIDACT是一个多任务模型,在编辑、调试、修复和代码审查在内的开发活动上进行训练
研究人员在内部构建并部署了三个DIDACT工具,注释解析、构建修复和提示预测,每个工具都集成在开发工作流程的不同阶段 。
软件工程=交互日志
几十年以来,Google的软件工程工具链都是将与代码相关的每个操作都存储为工具和开发人员之间的交互日志 。
原则上,用户可以使用这些记录来详细重放软件开发过程中的关键变更过程,即Google的代码库是如何形成的,包括每一次的代码编辑、编译、注释、变量重命名等 。
Google的开发团队会将代码存放于monorepo(单仓库,mono repository)中,即包含所有工具和系统的代码存储库 。
软件开发人员通常在云中客户端(Clients in the Cloud, CitC)系统管理的本地写时复制(copy-on-write)工作空间中对代码修改进行实验 。
当开发者准备好将一组代码变更打包在一起实现某个任务时(比如修复某个bug),需要在Google的代码审查系统Critique中创建了一个变更列表(changelist, CL) 。
与常用的代码评审系统一样,开发人员与同行评审者会就功能和风格进行交流,然后编辑CL以解决评审注释时提出的问题 。
最后,评审员宣布代码「LGTM!(looks good to me)」,并把CL合并到代码存储库中 。
当然,除了与代码评审员的对话之外,开发人员还需要维护大量与其他软件工程工具的「对话」,包括编译器、测试框架、链接器、静态分析器、模糊测试工具等 。
谷歌公开自家「AI+软件工程」框架DIDACT:数千名开发者内部测试,用了都说生产力高

文章插图
软件开发中涉及的复杂活动网络的说明:开发人员的活动、与代码评审员的交互以及对编译器等工具的调用 。
软件工程中的多任务模型
DIDACT利用工程师和工具之间的交互对机器学习模型赋能,通过建议或优化开发人员在执行软件工程任务时的行动,来辅助Google开发人员参与软件工程过程 。
为此,研究人员定义了一些关于单个开发人员活动的任务:修复损坏的构建、预测代码审查注释、处理代码审查注释、重命名变量、编辑文件等 。
然后为每个活动定义一个通用的形式:获取某个State(代码文件)、某个Intent(特定于某个活动的注释,例如代码评审注释或编译器错误),并生成一个Action(用于处理任务的操作) 。
其中Action就像一个迷你编程语言,可以扩展为新添加的活动,涵盖了编辑、添加注释、重命名变量、标记代码错误等内容,也可以称这种语言为DevScript 。
DIDACT模型的输入提示为任务、代码片段和与该任务相关的注释,输出为开发动作,如编辑或评论
状态-意图-行动(State-Intent-Action)的定义形式能够以通用的方式捕捉不同的任务,更重要的是,DevScript可以简洁地表达复杂动作,不需要像动作发生后那样输出整个状态(原始代码),使得模型更有效且更可解释 。
比如重命名可能会修改代码文件中的多处地方,但模型只需要预测一个重命名操作即可 。
给AI模型配个程序员
DIDACT在个人辅助任务上运行得非常好,比如下面的例子中演示了DIDACT在功能完成后的代码清理工作,先输入代码审查员的最终注释(图片中标记为human),然后预测解决注释中提出问题所需要的操作(用diff展现) 。


推荐阅读