• 文章地址
• CR的标准
• 在 CR 中要看些什么
• 如何浏览这次改动（CL）
• Review 的速度
• CR 要多快？
• 速度 vs 中断
• 快速回应

文章地址

原文地址：https://mp.weixin.qq.com/s/zIiDk7rcIKgvqh0YAvQPaA

英文地址：https://github.com/google/eng-practices/

CR的标准

• Reviewer 有责任保证CL的质量，作为Review的代码的Owner
• Reviewer不应追求完美，而应追求持续改进
• CR要具有指导意义
• 代码风格应该与现有的一致。如果项目没有统一风格，那就接受作者的风格
• 解决冲突难以达成共识时，需要面对面或者拉起更大的团队讨论，带上Leader

在 CR 中要看些什么

• 代码经过完善的设计
• 功能性对于使用者们是好的
• 对于任何UI改动要合理且好看
• 任何并行编程的实现是安全
• 代码不应该复杂超过原本所必须的
• 开发者不该实现一个现在不用而未来可能需要的功能
• 代码有适当的单元测试
• 测试经过完善的设计
• 开发者对于每样东西有使用清晰、明了的命名
• 注释要清楚且有用，并只用来解释why而非what
• 代码有适当的写下文件(一般在g3doc)
• 代码风格符合style guide
• 确保你查看被要求review的每一行代码、确认上下文、确保你正在改善代码质量，并赞扬开发人员所做的好事与优点吧!

如何浏览这次改动（CL）

步骤1: 用宏观的角度来看待改动，查看CL描述以及它做什么步骤2: 检查CL主要的部分步骤3: 用合理的顺序看CL 其余的改动

Review 的速度

为什么 Review 速度要快？

在Google我们优化开发团队 共同生产产品的速度，而不是优化个人开发的速度。个人的开发速度很重要，但它不如整个团队的开发速度重要。

CR 如果很慢，则：

①、团队整体的速度下降。

②、开发人员开始抗议 cr。

③、代码质量会收到影响。review 慢时，开发者提交的压力大。

CR 要多快？

如果你并没有处于需要专注工作的时候，那么应该在 review 完后尽快修改。回复最长的极限是一个工作日。

速度 vs 中断

我们可以在投入到处理他人给的review评论之前，找个适当的时机点来进行cr。这有可能是当你的当前开发任务完成后、午餐、刚从会议脱身或从微型厨房回来等等。

快速回应

个人回应评论的速度，比起让整个 cr 过程快速结束更重要。

 若在整个过程中能快速获得来自 reviewer 的回应，大大减轻开发者对缓慢 cr 过程的挫败感。

 reviewer员要花足够的时间来进行review，确保他们给出的LGTM，意味着“此代码符合我们的标准”。

 理想的个人的回应速度还是越快越好。