# 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，需结合代码库整体上下文做评估。