代码评审最佳实践
“Code Review is not just about finding bugs — it’s about learning, growing, and building better software together.”
为什么要做 Code Review？
代码评审（Code Review）不仅仅是为了找 bug，更是为了提升代码质量、促进知识共享、减少技术债、统一代码风格，以及提升整个团队的工程文化。
一、基本原则
✅ 1. 以人为本（Be Kind and Respectful）
- 审代码不是审人，永远避免指责。
- 用建议性的语气表达，比如：
- “也许我们可以这样写会更清晰？”
- “这里有没有考虑 xxx 情况？”
✅ 2. 保持目标一致
- 聚焦：代码质量 > 性能 > 结构 > 风格。
- 不纠结于个人偏好，遵守团队规范。
✅ 3. 小步提交，小步审核
- 避免一次提交几百行改动。
- 理想的 PR 规模：200 行以内最佳（Google 内部推荐），最大不超过 400 行。
二、Code Review 的流程建议
🧠 提交方（Author）责任：
- 做好自检：提交前运行 Linter、Test。
- 详细 PR 描述：说明改动的动机、上下文、关键变更点。
- 合理拆分提交：按功能/逻辑组织 commit。
- 标记重点：可使用注释指出 Reviewer 应重点看的逻辑。
👀 审查方（Reviewer）责任：
- 通读 PR 描述 和相关需求文档。
- 关注以下几个层级：
- 是否符合功能/需求？
- 是否有明显 bug、边界未处理？
- 代码是否易读、易维护？
- 是否破坏已有结构？是否引入重复代码？
- 测试是否覆盖到关键逻辑？
- 做有建设性的反馈：
- 标出问题，但提出建议更重要。
- 能接受则 approve，不能接受则 request changes。
三、代码风格建议
- 遵循项目代码规范（如 gofmt, eslint, clang-format）。
- 命名清晰，不要省略，保持一致性。
- 拒绝魔法数、复制粘贴、超长函数。
- 合理使用注释，但不替代清晰的代码本身。
四、常见 Code Review 误区
| ❌ 误区 | ✅ 改进建议 |
|---|---|
| 太过关注代码风格的小问题 | 自动化交给 Linter，Review 聚焦逻辑 |
| 提交巨大的 PR | 拆小，每次只处理一个问题或功能点 |
| Reviewer 不了解上下文就点评 | 提前看 PR 描述和相关需求文档 |
| 评论太强硬或模糊不清 | 提供具体例子和建议，保持礼貌 |
| 忽视测试或只看代码表面 | 检查边界条件、容错处理和测试覆盖 |
五、工具辅助推荐
| 工具 | 用途 |
|---|---|
| GitHub/GitLab PR/ MR | 主流代码评审平台 |
| ReviewDog / Danger | 自动化审查工具，集成 CI |
| pre-commit / husky | 提交前格式检查工具 |
| Codecov / Coveralls | 测试覆盖率检测 |
| SonarQube | 静态分析 & 代码质量检测平台 |
六、总结
高效的 Code Review 不仅能发现问题，更能提升团队协作和代码质量。通过构建积极、建设性的评审文化，团队成员能互相学习、共同进步。记住：
🔁 “Code Review 是一场持续的对话，而不是一场辩论。”