代码审查不是找茬，是知识共享和质量保障。本文给出可落地的审查清单和流程规范。

一、代码审查的目标

  • 1.1 发现问题——Bug、安全漏洞、性能问题
  • 1.2 知识共享——团队成员互相学习
  • 1.3 规范一致性——代码风格和架构统一

二、审查流程规范

  • 2.1 MR/PR 的粒度——不超过 400 行
  • 2.2 审查时效——24 小时内完成
  • 2.3 审查角色——至少 1 人，核心变更至少 2 人
  • 2.4 审查工具——GitLab MR / GitHub PR

三、审查清单

  • 3.1 功能正确性——是否满足需求
  • 3.2 异常处理——是否覆盖边界条件
  • 3.3 并发安全——线程安全性
  • 3.4 数据库——是否有 N+1 查询、缺少索引
  • 3.5 安全——SQL 注入、XSS、敏感信息
  • 3.6 日志——关键操作是否记录
  • 3.7 测试——单元测试覆盖率

四、审查评论规范

  • 4.1 P0——必须修改（阻塞合入）
  • 4.2 P1——应该修改（建议合入前修改）
  • 4.3 P2——锦上添花（本次或下次）
  • 4.4 评论的语气——对事不对人

五、静态检查工具

  • 5.1 SonarQube——代码质量门禁
  • 5.2 Checkstyle / PMD / SpotBugs
  • 5.3 集成到 CI 流水线

六、推动代码审查文化

  • 6.1 从团队 Leader 开始以身作则
  • 6.2 新人前 3 个月的代码必须审查
  • 6.3 定期分享审查中发现的好案例

七、总结

  • 代码审查是团队效率的乘法因子
  • 好的审查文化需要刻意培养