Appearance
代码审查（Code Review）
代码审查（Code Review）是现代软件开发中保证代码质量的核心实践，通过 Pull Request / Merge Request 机制实现。
Pull Request / Merge Request 流程
创建 PR 的标准流程
bash
# 1. 从主线创建功能分支
git switch main
git pull origin main # 确保从最新代码开始
git switch -c feature/user-avatar
# 2. 开发功能并提交
git add .
git commit -m "feat(user): 添加用户头像上传功能"
git commit -m "test(user): 为头像上传添加单元测试"
# 3. 推送分支到远程
git push -u origin feature/user-avatar
# 4. 在 GitHub/GitLab 创建 PR（通过 Web 界面或 CLI）
gh pr create --title "feat: 用户头像上传功能" --body "..."PR 描述模板
在仓库根目录创建 .github/pull_request_template.md：
markdown
## 改动内容
简要说明做了什么改动
## 动机与背景
为什么需要这个改动？解决了什么问题？
Closes #（Issue 编号）
## 改动类型
- [ ] Bug 修复（非破坏性改动，修复了一个问题）
- [ ] 新功能（非破坏性改动，新增功能）
- [ ] 破坏性变更（现有功能可能受影响）
- [ ] 文档更新
## 测试说明
- [ ] 已添加单元测试
- [ ] 已通过本地测试
- [ ] 测试步骤：
1. 步骤一
2. 步骤二
## 截图（如有 UI 改动）
| 改动前 | 改动后 |
|-------|-------|
| 截图 | 截图 |
## 自查清单
- [ ] 代码遵循项目规范
- [ ] 已自我审查代码
- [ ] 已更新相关文档
- [ ] 没有引入敏感信息Review 最佳实践
对提交者的建议
提交 PR 前的自查：
bash
# 1. 确保基于最新主线
git fetch origin
git rebase origin/main
# 2. 运行本地测试
npm test
npm run lint
# 3. 检查自己的改动（重要！先自己 review 一遍）
git diff origin/main..HEADPR 大小控制（小而聚焦的 PR 更容易被 review）：
❌ 一个 PR 包含多个不相关的功能（难以 review）
✅ 每个 PR 只解决一个问题或实现一个功能
理想的 PR：
- 文件改动 < 400 行
- 关注单一问题
- 有清晰的标题和描述对 Review 者的建议
Review 关注点：
优先级从高到低：
1. 正确性
- 逻辑是否正确？
- 边界情况是否处理？
- 错误处理是否完善？
2. 安全性
- 是否有 SQL 注入、XSS 等安全漏洞？
- 是否有敏感信息泄露？
- 权限控制是否正确？
3. 性能
- 是否有明显的性能问题？
- 数据库查询是否合理？
4. 可维护性
- 代码是否清晰易懂？
- 是否遵循项目规范？
- 是否有必要的注释？
5. 测试
- 测试覆盖是否充分？
- 测试是否有意义？Review 评论技巧：
前缀规范：
nit: 小问题，可改可不改（nitpick）
nit: 变量名可以更具描述性，如 userList → users
q: 问题/疑问
q: 这里为什么要用 setTimeout？有什么特殊考虑吗？
suggestion: 建议（非强制）
suggestion: 可以考虑使用 Map 替代 Object，性能更好
blocker: 必须修改（阻止合并）
blocker: 这里没有处理 null 值，会导致 NPE处理 Review 意见后的更新方式
方式1：追加新提交
bash
# 根据 review 意见修改
vim src/user.js
# 追加新提交
git add .
git commit -m "fix: 根据 review 添加空值检查"
git push
# PR 自动更新，review 者可以看到改动方式2：修改原有提交（整理后的 PR）
bash
# 如果想保持整洁的提交历史
# 修改特定提交（使用 fixup 工作流）
git add .
git commit --fixup=abc123 # abc123 是需要修改的原始提交
# 或者直接 amend 最近提交
git add .
git commit --amend --no-edit
# 整理历史
git rebase -i --autosquash origin/main
# 强制推送（PR 中 force push 需要 review 者重新 review）
git push --force-with-lease两种方式的选择：
- 追加新提交：review 者容易追踪新改动，PR 历史清晰
- 修改原提交：最终 merge 历史更整洁，但需要 force push
fixup + autosquash 工作流
这是一种高效的 PR 清理工作流：
bash
# 开发过程中
git commit -m "feat: 添加用户头像功能" # 主功能提交
# 发现小问题，修复
git commit --fixup HEAD # 或指定特定 commit SHA-1
# review 要求修改
git add .
git commit --fixup abc123 # abc123 = feat 提交的 SHA-1
# PR 批准后，整理提交历史
git rebase -i --autosquash origin/main
# fixup 提交会自动合并到对应的 feat 提交中
git push --force-with-lease
# merge 到主线（现在历史是整洁的）总结
| 实践 | 说明 |
|---|---|
| 小型 PR | 每个 PR 只解决一个问题，< 400 行 |
| 清晰描述 | 使用模板，说明原因而不只是做了什么 |
| 先自审 | 提交前自己 review 一遍 |
| 及时响应 | Review 意见应在 24 小时内响应 |
| 礼貌沟通 | 建议而非命令，询问而非假设 |
| fixup 工作流 | 保持最终提交历史整洁 |
良好的 Code Review 文化不仅能提升代码质量，还能促进知识共享和团队成长。记住：Review 的目的是让代码更好，而不是找错。