谷歌工程实践-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并不在于遇见了多不同的问题，而是遇到了相同问题所采取的方案更为科学。聪明的人总是透过现象看本质，予以根本性解决。