0%

谷歌工程实践-CR,MR

最近花个把小时阅读了谷歌工程实践,当然现在只有CR,MR部分,但是仍然很有触动。这里谈下个人的感受

官方文档:戳这里

CL的规范化

  1. CL means changelist
  2. CL提交新的subject,采用祈使句,一个命令的形式言简意赅的表达这次提交的改变是什么,如果需要详细的上下文,关联的卡号,就在body中说明。
  3. 有些人会积攒一堆的change,一次性的提交,然后在一次性的MR,实际上大量的change增加了review的风险,MR的风险和回滚的风险。所以刻意训练分解问题,确保每次的CL尽可能的小,是有利可行的。

MR的规范化

  1. 紧急的MR,我们可以适当的放松规则,放松要求,毕竟有些提交如果不及时的合并进去,会造成商业的损失
  2. MR中comment不能带有脾气,我们的目的始终是基于问题点讨论,帮助开发者成长
  3. 针对具体的代码风格,如果没有既定的规则,就要去接受。
  4. 针对做的好的给予赞誉和肯定。
  5. LGTM means looks good to me
  6. MR中的冲突处理,有必要的要联系开发者,一块去参与决定,避免出现代码丢失及错误

CR的规范化

  1. 速度可以消除一部分的抱怨,不能让CR时间拉的太长。
  2. CR发现的问题,要让开发者去修改,尤其是严重的。因为所谓的以后再修改,这样的想法才是系统变得更差的广泛原因。

写在最后

  1. 之所以觉得谷歌这个实践总结的很好,是因为其中描述到的问题,作出的解释,确实是我在实际推进Team做CR,MR所遇到的问题,痛点。这里给出了很好的理论基础。
  2. 我想好的公司,好的team并不在于遇见了多不同的问题,而是遇到了相同问题所采取的方案更为科学。聪明的人总是透过现象看本质,予以根本性解决。