代码审查最佳实践：高效Review流程、反馈文化与团队协作标准
代码审查有多重目的：发现Bug和安全漏洞（质量保证）；确保代码符合架构和设计标准（一致性）；在团队间传播知识（知识共享）；为初级工程师提供学习机会（人才培养）。但实践中，Code Review容易陷入两个极端：流于形式（只看格式，橡皮图章式批准）或过于主观（陷入风格争论，造成不必要的延迟和摩擦）。
作为Reviewer的最佳实践
区分必须修改（Blocker）和建议（Non-blocker）：Bug、安全漏洞、明显的逻辑错误是Blocker；代码风格偏好、命名建议是Non-blocker（可以用”Nit:”标注）。混淆两者会使作者不知道哪些问题必须解决，哪些可以忽略。
解释”为什么”，而不只是”什么”：`这里应该用map而不是for循环`比`为什么用这个？`好，但`这里用map可以使意图更清晰，因为…`最好。解释原因帮助作者学习，而不只是执行修改。
关注代码，不针对个人：`这段代码…`而非`你写的代码…`的表述差异在某些团队文化中影响显著。
作为Author的最佳实践
小PR原则：一个Pull Request应该做一件事，理想情况下改动在300-400行以内。过大的PR（1000+行）使Review质量显著下降。如果功能复杂，拆分为多个小PR分步合并。
写PR描述：清晰的PR描述（做了什么、为什么这样做、如何测试）减少Reviewer的理解成本，加快Review速度。GitHub的PR模板（`.github/pull_request_template.md`）可以标准化描述格式。
Google Engineering Practices文档（”Code Review Developer Guide”）是目前公开的最系统性的Code Review指南之一，是建立团队Review文化的重要参考。
