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)

2. 按文件拆分

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

3. 水平拆分

4. 垂直拆分

5. 水平和垂直拆分

重构保持单独的CL

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

不要破坏build

不能写出小的CL

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