这个系列计划写3篇
-
上篇：笔者公司基于 GitLab 的 code review 流程分享；
-
中篇：结合 GitLab 的 webhooks、merge request 以及钉钉群 GitLab 消息机器人，实现 code review 的半自动化；
-
下篇：笔者基于 nodeJs 开发的全自动消息通知服务（已开源）：结合 GitLab 的 webhooks 和钉钉群自定义机器人，将评论，merge request 等消息及时推送到钉钉群并@对应同学继续后续流程，让整个 code review 更加丝滑；
为什么要做 Code Review?
掘金上搜 code review，文章都写的很棒，受益匪浅，但笔者发现，大家做 code review 的原因各式各样，唯独少了我想说的2个点。
第1点：为快乐！
有同学会好奇，是 judge 别人的快乐嘛？当然不是的，是为了快乐的工作。
仔细回忆一下，我们呆过的公司，团队，项目，有多少痛苦是来自于维护质量参差不齐的老代码？相信不少同学都有过这种体会，甚至不乏有同学用“屎山”形容自己接过来的项目代码。如果不得已要继续在这种项目里继续写代码（当然可以选择重构，那就是另外一个话题了），“搅屎棍”这个词怎么感觉挺贴切😂。
大多数人应该都不会喜欢“搅屎棍”的感觉，一点也不快乐，大家都想快乐的工作。所以，从自己做起，从自己的团队开始，把“屎山”代码扼杀于摇篮之中，那么，code review 是一剂良药。
做 code review -> 提升代码质量 -> 更高质量的 code review -> 更高质量的代码 -> ...，良性循环，从此和“屎山”代码说拜拜。
这就是：为快乐。
第2点：为成长。
选择做 code review 的第二个初衷很理性，就是为了成长。
被 review 的工程师，有机会了解到更优的解决思路，更好的代码实现方式，这一定程度上就是别人在带着你成长，手把手教你提升代码质量，还免费，不要太爽对不对？
做 review 的工程师，有机会把自己熟悉的最佳实践分享给其他同学，这也是一种强化知识的过程，会让我们更加深刻的思考，另外，也不乏有机会学习更好的代码实现，对自己也是一种提升。
双赢，这也是在笔者的团队推动 code review 的核心初衷之一。
怎么做 Code Reveiw？
目前笔者团队的流程具体如下：
- 开发同学基于 master 分支（最新代码所在分支）拉取个人的开发分支，示例名称比如：feature_code_review；
- 开发同学在 feature_code_review 分支上进行开发和代码提交（关于 commit 规范这里就不展开了，另外的话题）；
- 当完成一个较为完整的功能模块之后（建议1000行以内的代码量），就可以将这部分代码通过 GitLab（笔者公司代码通过 GitLab 管理，自有架设的代码仓库） 的 merge request 提交到开发分支 trunk（分支名可以根据自己团队具体规则定即可）;
- merge request 提交的时候 assignee 选择当前项目的 owner 或任意同学，title 和 description 要尽可能清晰地描述此次 review 的代码内容；
- 当一个 merge request 提交之后，会将对应的 merge request 消息推送到对应的钉钉群里，并自动 @ 对应的 assignee；
- 被 @ 的同学执行 code review，通过 GitLab 的代码评论功能提出自己的意见和想法（关于如何评论，掘金的这篇文章写得很棒：8 个 Tips 让你更好的进行 Code Reivew）；
- 执行 code review 同学的评论会实时的通过钉钉群消息 @ merge request 的提交同学，同时，在 GitLab 的评论里 @ 的任何人也会通过钉钉群消息收到通知；通过这个机制，评论和被评论的人就可以及时的收到最新的 review 进度；
- 最后所有的 discussion （讨论）都被关闭之后，本轮 code review 完成，执行 code review 的同学可通过评论输入 “1” 或者直接 @ 上级主管进行二次 code review;
- 上级主管二次 code review 完成之后，评论输入 “1” 即表明本轮 code review 最终完成；
- 此时提交 merge request 的同学会收到钉钉群消息通知，确认之后，关闭所有 discussion（讨论），合并 merge request 进入开发分支即可。
如上就是笔者所在团队的完整的 code review 流程，当然一些执行规则也在实验当中，一些 review 的流程可能并不适合所有的团队，欢迎讨论和分享大家的最佳实践。
有同学就会有疑问了，这里多次涉及到了钉钉群消息通知，而不需要在GitLab上每次操作之后，人肉去@对应的同学，这是怎么做到的呢？
这就是下篇要分享的内容：结合 GitLab 的 webhooks、merge request 以及钉钉群 GitLab 消息机器人，实现 code review 的半自动化。
