前几天看了《Code Review 法度榜样员的寄望与哀伤》，想到我们团队开展Code Review也有2年了，结不雅还算比较知足，有些经验应当可以和大年夜家一路分享、商量。
我们为什么要履行Code Review呢？我们当时面对着代码纷乱、Bug频出的状况。
当时我认为要有所改变，欲望能进步产品的代码质量，改良开辟团队面对的困境。并且我小我在开辟上有很多经验，也欲望这些常识可以或许在团队内传播。
各类推敲后，我们最后认为履行Code Review能改良或解决我们面对的很多问题。

这篇文┞仿的目标不是告诉大年夜家怎么在一个团队内履行Code Review，起首因为我小我仅在一家公司内履行过，并没有很多经验。
所以，本文是介绍我们公司是若何实施Code Review的，我们是若何解决我们碰到的问题的，欲望我们的经验能给大年夜家带来些赞助。
行文仓促，如有漏掉或缺点，迎接斧正。

一、流程和规矩

Pull Request(PR)简单的说就是你没有权限往一个特定的仓库或分支提交卸码，你请求有权限的人把你提交的代码大年夜你的仓库或分支归并到指定的仓库或分支。
因为PR须要有权限的人确认，所以异常合适在这个过程中做Code Review，是否接收或者拒绝就取决于Code Review的结不雅。
在支撑PR模式的软件里，每一个PR都有一个新增代码的比较（diff）界面。
评论可以被所有有权限查看仓库的人看到，每小我都可以答复任何人的评论，有点像论坛里某个帖子的评论辩论。
这种模式是过后审核，也就是代码已经提交到了中间仓库，Review过程中频繁的修改会造成汗青签入记录的纷乱。
当然Git可以采取更改汗青记录来解决这个问题，因为轻易误操作，我们一般只在基本类库这类请求比较严格的项目上实施。

因为Git太灵活了，是以出生了很多的Git流程，用来规范Git的应用。
我们对Git Flow做了些调剂，调剂后的流程被定名为Baza Flow，定义见后文。
根据Baza Flow，我们大年夜部搀扶库只定义了2个骨干分支，master和develop。(例外，我们有一个仓库有3个开辟小组同时进行开辟，定义了4个骨干分支，今朝还比较顺畅，再多估计骨干分支之间的归并就比较繁琐了。)
其次每家公司、每个团队的情况都不太一样，应当根据公司或团队的实际情况选择恰当的筹划，并根据成员的反馈来及时调剂，推动Code Review的实施。
master对应临盆情况代码，所有面向临盆情况的宣布来源都是master分支的代码。develop则对应本地测试情况的代码。
绝大年夜多半情况下，QA（测试）只测试develop分支和master分支的代码。

因为开辟人员都在一个团队内，所以我们没有采取基于仓库的PR，采取的是基于分支的PR。
我们对骨干分支的操作权限做了限制，只有特定的人才能操作，develop分支是项目开辟Leader和架构师，master分支是QA。
有权限往骨干分支归并的成员会按照商定的规矩来履行归并，不会归并没有完成审核的PR。
膳绫擎这点其实蛮重要的，所以我们会对有权限归并的人有特其余商定，在什么情况下才能归并代码。（见后文PR的解释）
PR的提议人要主动的推动PR的审核，Leader也会密切存眷PR审核的进度，在须要的时刻及时介入。

我们设备了CI办事器（什么是CI）只编译特定的分支，平日是develop和master分支。
所有的代码归并到了骨干分支之后，都邑主动触发编译和本地测试情况的宣布，QA无需依附开辟人员编译的代率攀来测试，也无需本身手工操作这些，包管了开辟人员和测试人员的互相自力。
我们本地测试情况的宣布包含了数据库和站点的宣布，全主动的，宣布完成今后就是一个可用的产品，有时光┞封部分也可以分享一下。

 Baza Flow

我们还应用了Scrum琅绫擎一个很重要的概念：完成定义。
就是我们规定了我们一个义务的完成被定义为：代码编写完成，经由自测，提交的PR经由审核并且归并到骨干分支。
也就是说，所有的代码被归并到了骨干分支之后义务才算是完成，而被归并到骨干分支必须要经由Code Review，这是强迫的。

当前版本 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分支创建特点分支即可。

　　推荐阅读

　　Vue.js和MVVM小细节

【技巧沙龙】AI开辟者拭魅战营-7分钟打造1个定制技能。7月22号，我们等你一路！ 这种 MVC 架构模式对于简单的应用来看起是OK 的，也相符软件架构的分层思惟。 但实际上，跟着H5 的赓续成>>>详细阅读

本文标题：我们是怎么做Code Review的

地址：http://www.17bianji.com/lsqh/36317.html

 1/2    1