有效评审先理解变更目标和上下文，再检查正确性、失败路径、并发、安全和兼容性。格式问题应交给自动化工具，不值得消耗主要注意力。

从风险开始

数据迁移是否可回滚，接口是否破坏旧客户端，事务失败后状态如何，日志是否泄露敏感信息，这些问题通常比变量命名更重要。评审意见应说明可能出现的场景和影响，而不只是说“这样不好”。

较大的变更应拆成容易理解的提交，并在描述中给出验证方法。作者有责任降低评审者重建上下文的成本，评审者也应区分必须修改的问题和个人建议。

评审不能替代测试和架构设计，但它能让隐含假设公开化。好的结果不仅是合并了一段代码，也是团队对系统行为形成了共同理解。