基于大模型的 Code Review 实践

2,777 阅读3分钟

image.png

由于降本增效的浪潮,公司最近在做研发效能方面的研究,其中如何做好利用AI Code Review 也是一个方面。

公司的代码仓库用的是 Gitlab 私有化部署,在 GitHub 上搜索关键词 GPT Gitlab Code Review 可以看到的项目很少,所以我们就准备单干。给大家造轮子用🚗😊。

(🍭我们的项目是倒数第二个 欢迎尝试、传送门🚀

image.png

我们准备做一款基于Gitlab的 结合GPTCode Review(下文称作CR) 的开源工具给大家使用🎁

我们的项目有什么特点?🤔

这个项目有什么特点? ✨

🐶 针对于 Gitlab 定制

🐱 结合了GPT的能力 🚀

🦊 正在尝试接入私有化 LLM 解决代码安全问题

🦁 我们将一直关注效能研发 最新的Coder Review动态 融入这个项目

这是我们目前实现的一些功能✨

基于Merge Request 触发的针对于文件修改的Code Review 🚗

GPT 给出的评审结果

1. 😊代码评分

2. ✅代码优点

3. 🤔代码存在的问题点

4. 🎯修改后的代码

image.png

Code Review 相关信息进行信息推送

image.png

项目架构

image.png

架构分析

目前的架构主要分为逻辑处理GPT静态分析 三个模块儿(一图胜千言😄)

1. 逻辑处理

逻辑处理是针对于 Gitlab 的 webhook 推送的内容进行逻辑处理,提供类似于控制触发 CR 条件消息通知避免对文件进行重复 CR限制CR文件类型

2. GPT

在GPT模块儿中提供访问GPT的能力,并将需要CR的内容添加提示词上下文对GPT进行限定输出内容等工作。

graph LR
用户发起MR --> diff两个分支 --> 获取被修改的文件列表 ---排除非必要CR文件--> 获取每个文件修改的内容 --> 添加上下文 -->将修改的内容发送给GPT 

实现逻辑:目前是针对文件Code Review的,当用户发起 MR 的时候,我们diff两个分支的文件差异,将每个文件的修改内容发送给GPT进行分析

3. 静态分析(正在开发⏰)

中心功能为深度风险指数广度风险指数

深度风险指数:通过修改代码的行号定位到修改的函数名,通过函数名和函数调用依赖关系链来反映此次修改的一个代码变更风险等级,列入这个函数位于一个函数调用链的底端,则说明这个函数中代码修改后影响的链路比较长,此次修改代码的风险指标就比较高

graph LR
main --> A --> B --> C --> D --> F(F)
	style F color:#ffffff,fill:#300fa9,stroke:#a67eb7

广度风险指数:通过修改代码的行号定位到修改的函数名,通过函数名静态分析函数在代码库中出现的次数,如果出现次数比较多,则说明此函数的重要程度也相对比较高,修改该函数的代码风险指标也比较高

graph LR
main --> API1 --> func1(func1) 
style func1 color:#ffffff,fill:#300fa9,stroke:#a67eb7
main --> API2 --> func2
main --> API3 --> func3
main --> API* 

🎯备注:在广度代码风险指数这个指标中,可能会有特殊的情况,举个例子比如说一个API接口调用了一个函数,这个接口调用的频率比价高,但是这个函数在代码仓库中只出现了一次,修改改了这个函数的风险指标也是应该比价高的,所以说静态分析只能反映一部分问题。(这个问题可以用流量录制来解决😊)

项目接下来的工作⏰:

  • ✅ 使用 GPT 进行Code Review
  • 尝试接入私有化大模型解决代码安全问题
  • 可以配置更多的触发方式
  • ✅ Merge Request触发
  • commit触发
  • tag触发
  • 兼容飞书的消息通知
  • ✅ 兼容钉钉的消息通知
  • 结合静态代码分析来提供修改代码的风险等级

如果你有任何比较好的想法和建议欢迎与我们沟通联系。

欢迎star👏🏻 github.com/mimo-x/Code…

参考文章 📚