- 文章地址
- 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，意味着“此代码符合我们的标准”。
理想的个人的回应速度还是越快越好。
