“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 是一场持续的对话，而不是一场辩论。”
📚 延伸阅读
Google Code Review Developer Guide
StackOverflow Engineering Code Review Guide
Code Review 101 - GitLab Docs