核心要点
关注正确性与边界:逻辑是否正确、异常与边界是否覆盖
关注可读性与设计:命名、结构、职责划分、可维护性
关注测试与安全/性能:有无足够测试、有无安全与性能隐患
小批量提交、对事不对人,lint/CI 自动化先行减少人工纠缠
标准回答
评审关注的维度
- 正确性:逻辑是否实现需求,异常、并发、边界与空值是否处理到位。
- 可读性:命名是否表意、结构是否清晰、是否易于他人理解与修改。
- 设计:抽象与职责划分是否合理,是否引入不必要的复杂度或耦合。
- 测试:是否有覆盖关键路径与边界的测试,测试本身是否可靠。
- 安全与性能:是否存在注入、越权、敏感信息泄露,或明显的性能瓶颈。
高效评审的实践
- 小批量:每次评审控制在数百行内,过大的 PR 会让评审质量骤降。
- 对事不对人:评论针对代码而非作者,多用提问与建议的语气,区分「必须改」与「可选建议」。
- 自动化先行:把格式、lint、静态检查、测试交给 CI,人只评审机器评不了的设计与逻辑。
- 及时反馈:尽快响应,避免 PR 长期阻塞影响协作节奏。
目标是既保证质量,又传递知识、保持团队协作的健康氛围。
常见误区
⚠️ 常见踩坑
评审不是挑刺或纠结代码风格——风格应交给 lint 自动化;也不应放任超大 PR,否则评审会沦为「LGTM」式走过场。
追问
追问 1:面对一个超大 PR 该怎么办?
优先沟通拆分:请作者按功能或提交拆成多个小 PR 分批评审。若无法拆分,应分模块、分多次有重点地审,并明确说明评审局限,避免因疲劳而草率通过。
追问 2:如何给出建设性的评审意见?
对事不对人,先肯定再建议;用提问引导(「这里并发下会不会有竞态?」)而非命令;区分阻塞性问题与可选优化(如标注 nit);必要时给出具体改法或示例,降低对方理解和修改成本。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。