代码审查

代码审查（Code Review）是团队里 最便宜的质量保险：在 merge 前第二双眼睛看 diff，能抓逻辑漏洞、命名问题、遗漏测试。路线图 code-reviews 节点强调：Review 不是挑刺表演，而是 知识传递与风险拦截。

学习目标

• 掌握 PR 审查时的关注顺序与提问方式
• 会使用审查清单覆盖功能、测试、安全、可维护性
• 衔接 git-essentials 的分支与 PR 习惯

审查什么

建议按优先级：

1. 意图：PR 描述与 diff 是否一致？改对了问题吗？
2. 正确性：边界、错误路径、并发、空值
3. 测试：新行为有断言？失败信息可读？
4. 设计：职责是否清晰？是否引入不必要耦合？
5. 风格：命名、格式（可由 linter 兜底）

先问「为什么这样改」，再评「有没有更好写法」。避免只评论缩进而漏掉权限校验缺失。

PR 审查清单

类别	检查项
功能	需求覆盖完整？回归风险？
测试	单元/集成？Mock 是否合理？
API	破坏性变更？文档同步？
安全	输入校验、鉴权、无 secrets
可维护	方法长度、重复、注释必要处

Java 后端可对照 spring-boot-essentials 的校验与异常；AI 辅助写码时额外看 ai-coding-essentials 的幻觉与过度改动清单。

好的 Review 评论

• ✅ 「这里 userId 为空时会 NPE，建议 early return 或 Optional」
• ✅ 「能否抽 validateTrackSlug 复用？第三处复制了」
• ❌ 「写得不行，重写」（无具体信息）

作者侧：小 PR、自测通过、描述含 Test plan，见 cq-pr。Review 与 testing-essentials 的金字塔思维互补：测证明行为，Review 看设计与遗漏。

练习

• 在 GitHub 找一个小 PR，按本节清单写 3 条 constructive 评论（可不提交）
• 读 git-merge，记录冲突时 Review 应关注什么
• 为自己最近一次 commit 做「自审」：若别人 Review，最可能被问什么？

小结

有效 Review = 意图对齐 + 清单覆盖 + 具体可执行的反馈。 下一课学重构：在测试保护下安全改善结构。