Google工程实践 - 小修改(CL)

https://google.github.io/eng-practices/review/developer/small-cls.html

Intro

CL是指Changelist,可与PR对应

为什么要写小的CL

  • review更快。对于reviewer来说,找出5分钟来容易,找出30分钟更难。
  • review更彻底。大的CL的review会变成形式主义
  • bug少
  • 如果reject了,浪费更少
  • 更容易merge
  • 更容易有好的设计
  • 当你在等review的结果时,更少的block
  • 更容易回滚

小是什么意思

  • 只与一个事情相关
  • 包含相关的测试代码
  • reviewer需要了解的所有相关事情都包含在CL中
  • 合入后,系统要能正常继续运行
  • CL不能小到难以理解,如果新加一个api,那api对应的用法也应该包含在CL中

没有硬条件,一般来说,100行合适,1000行就太大了。与相关的文件也有关,在一个文件中的200行修改还可以,如果一个CL涉及了50个文件,也太大了。

对reviewer来说,没有developer那么投入,所以可以提交比自己觉得更小一点的CL

什么时候可以用大的CL

  • 删除一个文件,可以视同一行修改
  • refactor工具造成的大规模改动,只要是预期内的

高效

如果你在编写一个小的CL后等待审阅者批准,然后再编写下一个CL,那么你将浪费很多时间。因此,你需要找到一种方法,在等待审查时不会阻止你的工作。这可能包括同时进行多个项目、寻找同意立即可用的审阅者、进行面对面审查、配对编程或以允许你在等待审查时立即继续工作的方式拆分你的CL。

拆分CL

  1. Stacked

将一个CL拆分成不阻止自己的一种方法是编写一个小的CL,将其发送给审阅,然后立即开始编写基于第一个CL的另一个CL。再发一个,再继续。这样就会形成堆叠在一起的CL(PR)

  1. 按文件拆分

按文件拆分,也会产生CL之间的依赖关系,需要工具管理

  1. 水平拆分

  2. 垂直拆分

  3. 水平和垂直拆分

重构保持单独的CL

测试代码与修改在同一个CL

不要破坏build

不能写出小的CL

应该总是有办法的,比如因为代码的架构不好,可以先写重构的CL,等架构好了,再写小的功能CL

comments powered by Disqus