82 lines
2.1 KiB
Markdown
82 lines
2.1 KiB
Markdown
# Code Review 流程
|
||
|
||
## 触发场景
|
||
|
||
收到 MR/PR 需要评审时。
|
||
|
||
## 准备
|
||
|
||
切换到对应分支并获取变更内容：
|
||
|
||
```bash
|
||
# GitLab
|
||
glab mr checkout <MR_ID>
|
||
glab mr view <MR_ID> | cat
|
||
glab mr diff <MR_ID> | cat
|
||
|
||
# GitHub
|
||
gh pr checkout <PR_NUMBER>
|
||
gh pr view <PR_NUMBER>
|
||
gh pr diff <PR_NUMBER>
|
||
```
|
||
|
||
## 评审流程
|
||
|
||
逐步执行以下维度。改动简单时可跳过某些步骤。
|
||
|
||
### 1. 理解业务目标
|
||
|
||
- 能否理解本次改动的业务目标？
|
||
- 如果目标不明确，先确认再评审。
|
||
|
||
### 2. High-level Review
|
||
|
||
- 改动是否放在了合适的位置？
|
||
- 是否尽可能复用已有实现？
|
||
- 是否有破坏现有设计与逻辑的可能？
|
||
|
||
### 3. Bug 检查
|
||
|
||
- 是否隐含业务错误、逻辑纰漏或安全问题？
|
||
- **未修改**的相关联代码是否有遗漏？
|
||
|
||
### 4. 代码清晰度
|
||
|
||
- 逻辑是否简洁易懂？
|
||
- 命名是否清晰合理？
|
||
- 一年后再读，是否能轻松理解？
|
||
|
||
### 5. KISS 原则
|
||
|
||
- 是否有不必要的复杂度？
|
||
- 是否有未使用的定义、过多参数？
|
||
- 是否重复造轮子？
|
||
|
||
### 6. 单一职责
|
||
|
||
- 每个函数/类是否只做一件事？
|
||
- 文件/类/方法行数是否合理？
|
||
|
||
### 7. 测试覆盖
|
||
|
||
- 复杂业务逻辑（含 if/else/for）是否有测试？
|
||
- 测试是否有效（非空实现）？
|
||
- 不应过度测试无控制逻辑的代码。
|
||
|
||
## 输出
|
||
|
||
评审完成后，总结发现的**重点问题**，按严重性排列。
|
||
|
||
## AI 与人工的分工
|
||
|
||
| 维度 | 负责方 | 说明 |
|
||
| ---- | ------ | ---- |
|
||
| Bug、逻辑漏洞、安全问题 | **AI + 人工** | AI 负责初筛与证据收集，结论需人工复核 |
|
||
| 代码清晰度、KISS、单一职责 | **AI + 人工** | AI 提供候选问题，人工决定是否采纳 |
|
||
| 架构合理性、业务对齐 | **人工** | AI 反馈少且准确率低，需人工把关 |
|
||
| 兼容性、历史债务、战略取舍 | **人工** | 依赖背景知识，AI 难以判断 |
|
||
|
||
> 规则：AI 结论必须附文件路径、行号或可复现依据；缺少证据时按待确认假设处理。
|
||
>
|
||
> 注意：评审不只看 diff，需结合代码库整体上下文做评估。
|