核心要点

  • 关注正确性与边界:逻辑是否正确、异常与边界是否覆盖

  • 关注可读性与设计:命名、结构、职责划分、可维护性

  • 关注测试与安全/性能:有无足够测试、有无安全与性能隐患

  • 小批量提交、对事不对人,lint/CI 自动化先行减少人工纠缠

标准回答

评审关注的维度

  • 正确性:逻辑是否实现需求,异常、并发、边界与空值是否处理到位。
  • 可读性:命名是否表意、结构是否清晰、是否易于他人理解与修改。
  • 设计:抽象与职责划分是否合理,是否引入不必要的复杂度或耦合。
  • 测试:是否有覆盖关键路径与边界的测试,测试本身是否可靠。
  • 安全与性能:是否存在注入、越权、敏感信息泄露,或明显的性能瓶颈。

高效评审的实践

  • 小批量:每次评审控制在数百行内,过大的 PR 会让评审质量骤降。
  • 对事不对人:评论针对代码而非作者,多用提问与建议的语气,区分「必须改」与「可选建议」。
  • 自动化先行:把格式、lint、静态检查、测试交给 CI,人只评审机器评不了的设计与逻辑。
  • 及时反馈:尽快响应,避免 PR 长期阻塞影响协作节奏。

目标是既保证质量,又传递知识、保持团队协作的健康氛围。

常见误区

⚠️ 常见踩坑

评审不是挑刺或纠结代码风格——风格应交给 lint 自动化;也不应放任超大 PR,否则评审会沦为「LGTM」式走过场。

追问

追问 1面对一个超大 PR 该怎么办?

优先沟通拆分:请作者按功能或提交拆成多个小 PR 分批评审。若无法拆分,应分模块、分多次有重点地审,并明确说明评审局限,避免因疲劳而草率通过。

追问 2如何给出建设性的评审意见?

对事不对人,先肯定再建议;用提问引导(「这里并发下会不会有竞态?」)而非命令;区分阻塞性问题与可选优化(如标注 nit);必要时给出具体改法或示例,降低对方理解和修改成本。

延伸学习

与本题相关的知识库文章、术语、工具与行业资讯。