来自 Google 官方的代码评审最佳实践-摘录

  • 文章地址
  • 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,意味着“此代码符合我们的标准”。

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

评论已关闭。