在目前已使用的质量内建的工程实践中不可否认的一个实践为代码审查 它被用作提高产品交付质量和提高开发过程效率的有效措施。 Git又是目前当红的源码管理工具，若你的团队目前已经选用了GitLab来作为托管工具，那此文中你可以学到如何通过GitLab的Merge Request（合并请求）进行代码审查以及我们遵循的现有代码审查最佳实践来改进工作流程。

在我们讨论如何进行代码审查之前，让我们先来回顾一下代码评审的一般原则。

代码评审的一般原则

• 代码评审是任何开发过程中不可或缺的一部分 - 将其打印出来并放在墙上以便记住。可参考之前写过的你的代码评审需要来一次清单革命！
• 代码评审是在小段的逻辑完整的代码片段上执行的，例如功能，任务，错误修复，改进等。
• 只有通过审核的代码才会发送到测试部门。
• 该项目的所有开发人员都会进行代码评审，无论他们的级别如何。
• 项目的所有开发人员都应该通过代码评审，无论他们的级别如何（初级开发人员也应该审查经验丰富的中高级专家的代码）。

接下来我们将介绍如何使用GitLab提供的工具来进行代码评审。
GitLab中的merge request指的是把代码从一个分支合并到另一个分支上做的操作。

创建一个Merge request会涉及到的主要参数为：

• source branch
• target branch
• title
• description

• assignee

  
  
   

  

  content_Creating-merge-request.png

使用Merge Request时的操作步骤：

1. 编写代码并将其推送到单独的分支。
2. 为主要开发分支创建合并请求。 Assignee以及说明字段和评论中被提到的那些人将通过电子邮件通知合并请求。如果需要某一位开发人员关注，你可以在描述字段中@该名开发人员。
3. 等到MR被接受或拒绝，并提供有关必要修复的评论。
4. 参与有关修复的讨论。 （GitLab允许回复评论）
5. 修复。
6. 将更改推送到你的分支。
7. 打开一个新合并如果最后一个MR被关闭（如果合并请求未关闭，它将自动更新，直到最后一次提交为止）。
8. 通过注释合并请求或以其他方式报告已实施的修复。

 

content_reviewing-merge-requests.png

应该将Merge Request分配给谁

对于合并请求，它们的分配取决于各种因素。根据项目的人数和专业水平，可以有不同的选择。因此，如果您是团队中唯一的开发人员，请为自己分配合并请求。

否则，请与另一位在项目中独立的开发人员交谈，并让他审查彼此的代码。文档审查通常也是必要的，因为在您执行此操作后，您将确保其他开发人员可以在必要时使用您的代码。

如果您是项目的两名开发人员，请相互分配合并请求。如果有三个或更多开发人员，您可以自由选择。

你的团队可以在工作日的开始和结束时或根据要求随时进行代码审查。团队可以决定何时进行代码审查，最重要的是团队成员之间的持续协作。

用Merge Requests产生的代码评审如何进行更精细化的流程管理之后可以继续讨论。