前几天看了《Code Review 程序员的寄望与哀伤》，想到我们团队开展Code Review也有2年了，结果还算比较满意，有些经验应该可以和大家一起分享、探讨。
我们为什么要推行Code Review呢？我们当时面临着代码混乱、Bug频出的状况。
当时我觉得要有所改变，希望能提高产品的代码质量，改善开发团队面临的困境。并且我个人在开发上有很多经验，也希望这些知识能够在团队内传播。
各种考虑后，我们最后认为推行Code Review能改善或解决我们面临的很多问题。

这篇文章的目的不是告诉大家怎么在一个团队内推行Code Review，首先因为我个人仅在一家公司内推行过，并没有很多经验。
其次每家公司、每个团队的情况都不太一样，应该根据公司或团队的实际情况选择恰当的方案，并根据成员的反馈来及时调整，推动Code Review的实施。
所以，本文是介绍我们公司是如何实施Code Review的，我们是如何解决我们遇到的问题的，希望我们的经验能给大家带来些帮助。
行文仓促，如有遗漏或错误，欢迎指正。

一、流程和规则

经过简单的对比、试用，我们最后采用了Git Flow+Pull Request（PR）模式来做Code Review。（PR模式详情可参见 Git工作流指南：Pull Request工作流）

Pull Request(PR)简单的说就是你没有权限往一个特定的仓库或分支提交代码，你请求有权限的人把你提交的代码从你的仓库或分支合并到指定的仓库或分支。
由于PR需要有权限的人确认，所以非常适合在这个过程中做Code Review，是否接受或者拒绝就取决于Code Review的结果。
在支持PR模式的软件里，每一个PR都有一个新增代码的对比（diff）界面。
代码审核者可以在线浏览请求合并的新增代码，并针对有疑问的代码行添加评论，通过这种方式来实现Code Review。
评论可以被所有有权限查看仓库的人看到，每个人都可以回复任何人的评论，有点像论坛里某个帖子的讨论。
这种模式是事后审核，也就是代码已经提交到了中心仓库，Review过程中频繁的改动会造成历史签入记录的混乱。
当然Git可以采用更改历史记录来解决这个问题，由于容易误操作，我们一般只在基础类库这类要求比较严格的项目上实施。

我们所了解到的支持PR模式的软件都采用Git作为源代码版本控制工具，所以我们的源代码版本控制工具也迁移到了Git。
由于Git太灵活了，因此诞生了很多的Git流程，用来规范Git的使用。
常见的有集中式工作流、功能分支工作流、Gitflow工作流、Forking工作流、Github工作流。
我们对Git Flow做了些调整，调整后的流程被命名为Baza Flow，定义见后文。
根据Baza Flow，我们大部分仓库只定义了2个主干分支，master和develop。(例外，我们有一个仓库有3个开发小组同时进行开发，定义了4个主干分支，目前还比较顺畅，再多估计主干分支之间的合并就比较繁琐了。)
master对应生产环境代码，所有面向生产环境的发布来源都是master分支的代码。develop则对应本地测试环境的代码。
绝大多数情况下，QA（测试）只测试develop分支和master分支的代码。

由于开发人员都在一个团队内，所以我们没有采用基于仓库的PR，采用的是基于分支的PR。
我们对主干分支的操作权限做了限制，只有特定的人才能操作，develop分支是项目开发Leader和架构师，master分支是QA。
有权限往主干分支合并的成员会按照约定的规则来执行合并，不会合并没有完成审核的PR。
上面这点其实蛮重要的，所以我们会对有权限合并的人有特别的约定，在什么情况下才能合并代码。（见后文PR的说明）
PR的发起人要主动的推动PR的审核，Leader也会密切关注PR审核的进度，在需要的时候及时介入。

我们配置了CI服务器（什么是CI）只编译特定的分支，通常是develop和master分支。
所有的代码合并到了主干分支之后，都会自动触发编译和本地测试环境的发布，QA无需依赖开发人员编译的代码来测试，也无需自己手工操作这些，保证了开发人员和测试人员的相互独立。
我们本地测试环境的发布包含了数据库和站点的发布，全自动的，发布完成以后就是一个可用的产品，有时间这部分也可以分享一下。

我们还使用了Scrum里面一个很重要的概念：完成定义。
就是我们规定了我们一个任务的完成被定义为：代码编写完成，经过自测，提交的PR经过审核并且合并到主干分支。
也就是说，所有的代码被合并到了主干分支之后任务才算是完成，而被合并到主干分支必须要经过Code Review，这是强制的。

Baza Flow

当前版本 V0.9

Baza Flow 由 Git Flow 演化而来，Git Flow的开发模式如下图所示：

由于我们的托管软件对于Pull Request的限制，我们对Git Flow做了改动，改动的地方有：
1、每一个大功能我们会创建一个单独的feature分支，项目开发人员基于这个单独的feature分支创建自己的任务分支。
      比如，对于CS 2项目来说，启动的时候分支的创建是：master -> develop -> feature/v2。
      开发人员应该基于这个大特性分支feature/v2来创建自己的任务分支，比如创建XXXX，可以用一个单独的分支feature/v2-xxxx。
      完成这个任务以后，立即向上游分支（feature/v2）提交pull request。然后从feature/v2-xxxx 创建自己的下一个任务分支，比如YYYY编辑 feature/v2-yyyy。
      请注意，合并到上游分支的功能必须相对独立而且是可用的，分支任务工作量0.5-1个工作日，不宜超过2个工作日，超过2个工作日不向上游合并，需要向团队解释。
      代码经过Review以后，可能会进行必要的修改，修改在原分支修改，修改完毕代码合并进上游分支，原分支会定期删除。
      项目组成员在收到合并成功的通知后，请自行从上游大特性分支向下合并到自己当前的开发分支。
      提交pull request后创建新任务分支的时候务必知会一下相关配合同事（比如前端的同事），让他们在新的分支上继续开发。

2、对于小功能，预计在0.5-1个（不超过2个）工作日工作量的开发任务，直接基于develop分支创建特性分支即可。

（编辑：江门站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!