前几天看了《Code Review 程序员的寄望与哀伤》，想到我们团队开展 Code Review 也有2年了，结果还算比较满意，有些经验应该可以和大家一起分享、探讨。 我们为什么要推行 Code Review 呢？我们当时面临着代码混乱、Bug 频出的状况。 当时我觉得要有所改变，希望能提高产品的代码质量，改善开发团队面临的困境。并且我个人在开发上有很多经验，也希望这些知识能够在团队内传播。 各种考虑后，我们最后认为推行 Code Review 能改善或解决我们面临的很多问题。 所以，本文是介绍我们公司是如何实施 Code Review 的，我们是如何解决我们遇到的问题的，希望我们的经验能给大家带来些帮助。
一 流程和规则 经过简单的对比、试用，我们最后采用了 Git Flow Pull Request（PR）模式来做 Code Review。 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 服务器只编译特定的分支，通常是 develop 和master 分支。 所有的代码合并到了主干分支之后，都会自动触发编译和本地测试环境的发布，QA 无需依赖开发人员编译的代码来测试，也无需自己手工操作这些，保证了开发人员和测试人员的相互独立。 我们本地测试环境的发布包含了数据库和站点的发布，全自动的，发布完成以后就是一个可用的产品，有时间这部分也可以分享一下。 我们还使用了 Scrum 里面一个很重要的概念：完成定义。 就是我们规定了我们一个任务的完成被定义为：代码编写完成，经过自测，提交的PR经过审核并且合并到主干分支。 也就是说，所有的代码被合并到了主干分支之后任务才算是完成，而被合并到主干分支必须要经过 Code Review，这是强制的。 Baza Flow 当前版本 V0.9 Baza Flow 由 Git Flow 演化而来，Git Flow 的开发模式如下图所示： 由于我们的托管软件对于 Pull Request 的**，我们对 Git Flow 做了改动，改动的地方有：
|
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
