代码审查的多重目的：

1. 正确性：代码是否做了它应该做的？
2. 可读性：代码是否易于理解？
3. 一致性：代码是否符合团队规范？
4. 可维护性：代码是否易于修改？
5. 安全性：代码是否有安全漏洞？
6. 知识传播：审查者是否学到了新东西？

Google 的审查流程：

1. 作者提交变更（CL - Changelist）
2. 自动检查（lint、测试、构建）
3. 人工审查
   - 至少一个审查者批准
   - OWNERS 批准（如果需要）
4. 合并

审查速度目标：
- 1 个工作日内响应
- 小的 CL 优先审查
- 大的 CL 拆分审查

审查者应该关注：

1. 设计
   - 这个修改是否属于正确的代码位置？
   - 是否有更简单的设计？

2. 功能
   - 代码是否做了作者想要它做的？
   - 是否有边界情况没有处理？

3. 复杂性
   - 代码能否更简单？
   - 是否有不必要的抽象？

4. 测试
   - 是否有正确的测试？
   - 测试是否清晰、有用？

5. 命名
   - 变量名是否清晰？
   - 命名是否一致？

6. 注释
   - 注释是否解释了"为什么"？
   - 是否有过时的注释？

被审查者的最佳实践：

1. 小的变更
   - 每个 CL 只做一件事
   - 大的重构分多个 CL

2. 清晰的描述
   - 说明为什么要做这个修改
   - 说明如何测试

3. 积极回应
   - 快速回应审查意见
   - 解释不同意的理由
   - 接受合理的建议

4. 感谢审查者
   - 审查是无偿劳动
   - 感谢他们的时间

不好的评论：
"This is wrong."（这不对。）

好的评论：
"I think this approach might have an issue with null values. 
Consider using Optional<String> instead of String for the 
return type of getUserEmail(). This would make it explicit 
that the email might not be present.

What do you think about:

原则：
- 解释为什么
- 提供具体建议
- 保持尊重和开放