Code Review 最佳实践
Code Review（代码审核）是团队协作中保障代码质量的核心环节。
为什么需要 Code Review
| 价值 | 说明 |
|---|---|
| 发现问题 | 早期发现 bug 和设计缺陷 |
| 知识共享 | 团队成员互相学习 |
| 统一标准 | 保持代码风格一致 |
| 质量保障 | 提高代码可维护性 |
| 责任分担 | 多人共同维护代码 |
PR 作者最佳实践
提交前的准备
Bash
# 自检清单
1. 代码编译通过
2. 单元测试通过
3. 格式符合规范
4. 无明显 bug
5. 提交信息清晰
# 运行检查
npm run lint
npm run test
PR 信息规范
YAML
标题：简洁明了，说明做了什么
描述模板：
## 变更内容
- 具体修改了什么
- 为什么修改
## 测试情况
- 如何测试
- 测试结果
## 注意事项
- 需要注意的问题
- 可能的影响
## 关联
Fixes #issue-number
控制变更范围
Bash
原则：
- 一个 PR 只做一件事
- 变更文件数控制在合理范围
- 避免"顺手"修改无关代码
好处：
- 审核更聚焦
- 问题更易发现
- 回滚更方便
审核者最佳实践
审核重点
| 类别 | 检查内容 |
|---|---|
| 功能 | 是否正确实现需求 |
| 设计 | 设计是否合理 |
| 复杂性 | 是否过度复杂 |
| 测试 | 测试是否充分 |
| 命名 | 变量/函数命名是否清晰 |
| 注释 | 注释是否必要且准确 |
| 安全 | 是否存在安全隐患 |
审核原则
text
1. 尊重作者，友好沟通
2. 聚焦代码，而非个人
3. 提出建议，而非命令
4. 说明原因，而非只指出问题
评论风格对比
text
# 不好的评论
"这段代码很烂"
# 好的评论
"建议将这个函数拆分，
因为当前实现过于复杂，
会影响后续维护。
可以参考 similarFunction 的实现方式。"
审核响应时间
text
响应标准：
- 小 PR：< 24 小时
- 中 PR：< 48 小时
- 大 PR：< 72 小时
- 紧急 PR：尽快审核
不要阻塞：
- 审核不及时会阻塞开发进度
审核流程
text
创建 PR → 自检 → 分配审核者 → 审核 → 反馈 → 修改 → 通过 → 合并
↓ ↓ ↓
查看代码 添加评论 更新 PR
自动化检查
text
# GitHub Actions 示例
name: PR Check
on: pull_request
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- run: npm run lint
- run: npm run test
| 检查类型 | 工具 |
|---|---|
| 代码风格 | ESLint, Prettier |
| 单元测试 | Jest, pytest |
| 类型检查 | TypeScript |
| 安全检查 | SonarQube |
审核工具使用
text
# GitHub PR 审核
# 1. 查看文件变更
# 2. 在代码行添加评论
# 3. 选择审核结论
审核选项：
- Approve：批准，可以合并
- Request changes：需要修改后再审核
- Comment：仅评论，不改变状态
Code Review 的目标是提高代码质量，而非批评代码作者。
要点总结
- 作者自检后再提交 PR
- PR 信息清晰，控制变更范围
- 审核者聚焦功能、设计、测试
- 评论友好，说明原因和建议
- 及时响应，不阻塞开发
📝 发现内容有误？点击此处直接编辑