2.3　引导代码评审

在引导代码评审时，应务必确保合适的人员出席，并应当和项目经理就出席代码评审的人员达成一致。除非是远程协作，否则代码提交负责人应出席代码评审会。而在远程工作场景下，评审人将评审代码，并最终接受pull request、拒绝该pull request，或者将问题发送给开发者，待得到答案之后再行决定。

一个称职的代码评审引导人员应当具备以下技能和知识：

• 技术权威性：代码评审引导人员应当有一定的技术权威性，并理解公司的编码规范与软件开发方法。同时，对待评审的软件有良好的整体性了解也是非常重要的。
• 具备良好的软技能：代码评审引导人应当对提出建设性反馈的成员给予热情的鼓励。评审人员也需要拥有良好的软技能，以避免评审人和被评审人之间产生冲突。
• 不要过于挑剔：代码评审引导人员不能过于挑剔。他应当有能力恰当地解释这些针对开发者代码的批评意见。如果引导人员接触过多种不同的编程风格，并能够客观地看待代码以确保其满足需求，那么对代码评审将大有益处。

在我的工作经验中，开发者会将pull request提交到团队的版本控制工具上，而代码评审工作正是由pull request展开的。开发者首先将代码提交到版本控制工具上，并创建一个pull request。代码评审人审阅pull request中的代码。如有建设性反馈，则以评论的形式提出，并附加在pull request上。如果代码有较大问题，则评审人将拒绝此次变更请求，并将开发者需要解决的特定问题附加在评论中。如果代码评审通过，则评审人可以添加正向反馈，合并代码并关闭该pull request。

开发者应当关注并考虑评审人员的所有意见。如需重新提交代码，则开发者应当确保评审人所提出的问题均已在提交之前得到处理。

代码评审应尽可能保持短小，不要一次评审太多行的代码。

如上所述，代码评审通常是从pull request开始的，因此接下来我们将展示如何创建并响应pull request。

2.3.1　创建pull request

当我们结束编码工作、完成构建并对代码质量信心满满时，就可以将代码推送（push）或签入（取决于代码控制系统的种类）到代码控制系统中了。在代码推送完毕后可以创建pull request。pull request创建完毕后，所有对相关代码感兴趣的人员都将收到通知，并对变更进行评审。评审人可以对代码的变更展开讨论并发表评论，并指出任何需要进一步修改的部分。因此从本质上说，将代码推送到代码仓库并创建pull request是代码评审的起点。

如需创建pull request（假设代码已经推送或签入），只需在版本控制工具界面上点击Pull Request标签，随后单击New pull request（新建pull request）按钮。该操作将会将pull request添加到队列中等待相关评审人的审阅。

以下截图以GitHub为例展示了创建与处理pull request的过程。

1）在GitHub主页，单击Pull requests标签，如图2-2所示。

2）单击New pull request按钮。此时将会出现Comparing changes（变更对比）页面，如图2-3所示。

3）如果没有问题，则可以单击Create pull request（创建pull request）按钮开始创建流程。之后将跳转到Open a pull request（打开pull request）页面，如图2-4所示。

4）在该页面输入和当前pull request相关的描述。简明扼要地为代码评审人员提供所有必要的信息，例如识别所作的更改，并根据需要修改Reviewers（评审人员）、Assignees（指派人员）、Labels（标签）、Projects（项目）、Milestone（里程碑）等字段。在所有细节准备完毕后，单击Create pull request按钮创建pull request。此后评审人员就可以开始进行代码评审了。

2.3.2　响应pull request

评审人需要在将pull request分支合并之前进行代码评审。接下来将介绍响应pull request的步骤。

1）首先，复制一份待评审的代码。

2）其次，阅读pull request的评论并查看其中的变更情况。

3）确认该pull request不会和基础分支发成冲突。如果pull request和基础分支有冲突，则可以拒绝此次请求并在评论中进行说明。如果并不冲突则可以着手评审变更点，确认新的代码可以顺利构建，并且在编译过程中不会产生警告。除此之外，在这个阶段还需要确认代码是否存在坏味道或其他潜在的缺陷；测试是否能顺利构建并运行通过；测试覆盖率相对需要进行合并的功能来说是否足够。如果代码不尽如人意，那么请在评论中进行必要的说明并拒绝此次请求。如果代码令人满意，那么也请在评论中说明理由，并单击Merge pull request按钮合并pull request，如图2-5所示。

4）在页面中输入提交的注解并单击Confirm merge按钮确认合并操作，如图2-6所示。

5）当pull request合并并关闭后，就可以单击Delete branch按钮删除分支，如图2-7所示。

我们在前一节介绍了被评审人如何创建pull request以便开始进行代码评审和分支合并。在本节中介绍了在代码评审过程中如何评审并完成pull request。接下来，我们将介绍在响应pull request的评审过程中应该评审哪些内容。

2.3.3　反馈对被评审人的影响

在进行代码评审时，势必会产生正向反馈或负面反馈。负面反馈不会提供问题的细节，此时评审人关注的并非问题而是被评审人。这样的反馈并不能够将代码改进的建议传递给被评审人，反而是在伤害被评审人。

上述负面反馈对被评审人来说是一种冒犯，并会产生负面影响，因此被评审人可能会对自己产生怀疑。被评审人积极性降低，这会对团队产生负面影响，因为工作没有按时完成或达到要求的水平。团队会感受到评审人和被评审人的紧张关系，这种压迫性的氛围会对团队中的每一个成员造成负面影响，可能导致其他同事失去积极性，从而使整个项目陷入痛苦之中。

最终，当被评审人无法忍受时，可能会去寻找新的工作岗位以摆脱眼前的一切。由于需要花费时间和精力去寻找替代者，因此项目本身也会在时间和经济上受到影响。最终不论谁去填补这个职位，都需要再次接受系统方面的、工作流程以及规章制度方面的培训。图2-8展示了评审人对被评审人发出负面反馈后的影响。

相反，正向反馈会产生截然不同的效果。当评审人对被评审人提供正向反馈时，他们关注的是问题而非被评审人。他们会解释为什么提交的代码不够好以及提交后可能导致的问题。此外，评审人还会对代码改进的方法提出建议。因此，这种反馈的目的只在于提高被评审人提交的代码的质量。

当被评审人接到了正向（建设性）反馈之后，他们也会进行正向的回应。他们会积极考虑评审人的意见并以适当的方式来回答任何问题或主动提出任何相关的问题。代码将会依据评审人的意见进行更改。更新后的代码将重新提交以再次进行评审和验收。上述方式会保持积极的氛围从而对团队造成积极的影响。工作可以及时完成并完全符合质量要求。图2-9展示了评审人对被评审人积极反馈后的效果。

请注意，反馈可以是建设性的也可以是破坏性的。作为评审人，应当保持建设性而非造成破坏。快乐的团队将极具成效，而垂头丧气的团队则会效率低下，并最终对项目造成伤害。因此，请不断努力通过正向反馈来保持快乐的团队氛围。

正向的批评技术是一种三明治式的反馈技巧。首先从表扬优点开始，而后提出建设性的批评，最终再进一步表扬。如果团队中的成员对任何形式的批评的响应效果都不好，那么这种反馈技巧是很奏效的。请记住，与人交往的软技能和交付高质量代码的软件技能是同等重要的。

接下来我们将介绍如何确定评审内容。