Code Review 方法总结

定义

Code Review代码评审是指在软件开发过程中，通过对源代码进行系统性检查的过程。通常的目的是查找各种缺陷，包括代码缺陷、功能实现问题、编码合理性、性能优化等；保证软件总体质量和提高开发者自身水平。

之前团队使用的分支策略，贴近 git-flow。而基于git-flow 难以进行code review。后面采用git-flow结合gitlab-flow工作流作为分支管理策略。

code review 的好处

很多。略。

code review 形式

Team Review / Code Review Meeting：就是将团队成员都组织起来开会，让代码Owner上去讲自己代码的实现和思路，其它人发表意见和进行讨论，
Single Review：就是项目owner提交代码之后，让reviewer在空闲的时候帮忙评审代码，并且写出批注，owner收到批注后，进行修改或者回复。

peer review：reviewer 并不是只有组长/架构师才能做。需要所有经验丰富或有专长的同学参与其中。
架构师/负责人 review

建议采用single review。peer review 结合架构师review。例如：架构师review前，代码提交者可视情况申请经验丰富的同学做 peer review。

image.png

在feature分支merge到develop分支的时候做code review。
develop分支 merge 到 release时要控制合并的范围：因为develop会包含各个feature 分支合并上来的代码。但不一定所有feature都包含在此次发布的范围内。

code review 实施要点

使用GitLab进行Code Review就是在分支合并环节发起 Merge Request。然后Code Reviewer进行代码审核。
Code Reviewer review 完成后将代码合并到目标分支。
保证必须以Merge的方式变更develop分支、release分支、以及master分支。对Push以及Merge权限进行限制
IDEA插件：Gitlab projects Gitlab integration。发起Merge Request请求

附：几种分支管理策略

image.png

Git-Flow 工作流

master 和 develop 是长期分支。master 分支上的代码都是版本发布状态；develop 分支则代表最新的开发进度。

当需要开发某些功能时，就从 develop 拉出 feature 分支进行开发，开发完成并验证后就可以合并回 develop 分支。当 develop 上的代码达到一个稳定的状态，可以发布版本的时候，会从 develop 合并到 release 分支进行发布，如果验证有问题就在 release 分支进行修复，修复验证通过后进行正式发布，然后合并到 master 分支和 develop 分支。还有一个 hotfix 分支用来做线上的紧急 bug 修复，hotfix 直接从 master 拉出分支修改，修改验证完成后直接合并回 master，并同步到 develop 分支。

Git-Flow 流程非常完善，但会稍微有些复杂，而且没有图形页面。

GitHub 工作流

GitHub 工作流只有一个长期分支 master，而且 master 分支的代码永远是可发布状态。如果有新功能开发，可以从 master 分支上检出新分支，开发完成需要合并时，创建一个合并到 master 到 PR，也就是 pull request。当 review 通过或者验证通过后，代码合并到 master 分支。GitHub 工作流中 hotfix 热修复的流程和 feature 分支完全一样。

GitLab 工作流

GitLab 结合了前两者的优势，既支持 Git-Flow 的多分支策略，也有 GitHub Flow 的一些机制，比如 Merge Request和 issue 跟踪。GitLab工作流使用 pre-production 分支来进行预发管理，使用 production 分支来发布版本。

可以限定关键分支如：develop、master、release 必须以Merge的方式变更。对Merge和Push的权限进行限定。仅 Code Reviewer 具备这些分支的Push、Merge权限。

参考：

http://szuwest.github.io/code-reviewfang-an.html
Gitlab & IDEA 插件执行 Code Review 过程