Code Review

什么是Code Review

Code Review 中文的翻译方式有很多种“代码审查”，“代码评审”，“代码走查”等，个人更喜欢“代码走查”这种翻译。代码走查是一个流程，从开发人员在一个开发阶段写好代码后开始，之后需要别人以发现bug和技术交流为目的review一下他的代码。它是集代码审查，找出问题，改进代码和改后督查为一体的完整的流程。代码走查一般在代码刚刚出炉为最好，因为在这个时候也是代码重构和调整的最佳时候。

Code Review的目的及内容

功能性Review:
通过Review检查当前代码是否全部实现了需求里面全部的功能点，且功能正确。找出代码中的bug，每个人在写和读代码的时候都有固有的习惯，这样的一些习惯往往会影响代码的质量。比如：我们在代码编写过程中都出现过类似的问题，自己代码中的问题自己无论看了多少遍都发现不了，但别人一眼就能发现问题。出现这样的情况并不是说写代码的人水平不高而是个人编程中的“无意识”错误。当然这也就是结队编程的妙处。
可读性Review:
代码做为软件开发过程中最实时的文档，同时为了以后维护方便一定要有高度的可读性。可读性检查主要检查代码风格是否严格按照系统代码风格规定，代码中是否经过充分的重构消除了其中冗余重复的代码。代码结构是否合理。
分享技术知识：
“三人行必有我师”每个人的代码都有值得别人学习的地方，而且团队中各个成员水平高低不一，通过代码Review使水平高的人的技术逐渐流向水平低的人培养了新人。同时代码编写者向团队中的其他人介绍自己所用的技术和方法，这样一方面使各种技术在团队中得到共享。笔者在当前的公司里面遇到这样一个案例：
团队1在之前的项目开发中用到freetype做中文排版，但是当时没有做代码review。之后团队2也用到了freetype方面的知识但因为不知道团队1有freetype方面的知识，结果团队2又花费了大量的时间和精力去重新研究和学习freetype。这样大大延缓了项目的时间进度。
互为backup：
通过代码Review使更多的人了解当前模块的功能，这样减少了因人员流失而导致对项目产生的冲击。

态度决定一切

Code Review 做为软件开发中的一个重要环节，也是人参与和交互度比较高的一个环节，参与者对Code Review的态度将会很大程度上影响Code Review的效果。而程序员又是一群不善于同别人交流的一个群体，这样在Code Review的过程中可能因为对这件事的认识程度和态度的不同而会产生很大差距：

对于代码的讲解者来说，一些很有经验的程序员往往因为对Code Review的目的等方面认识不足容易犯这样一种错误，认为自己的代码不会有问题，这次Code Review就是给别人传道授业解惑的。这样会出现整个Code Review的过程基本抛弃了Code完全只讲他实现的思路和方法，完全成为了一个知识讲座，但要知道整体设计和具体实现还有很大不同。你的宏观思路很正确并不代表你的代码就没有一点问题。对于一些初来乍到的年轻人则会走向另一个极端，一说Code Review就像让他去刑场一样。就是为了去接受审判而去Code Review,完全依赖于自己的代码，没有把自己在这个过程中所学到的东西全部讲出来，这样也不利于整个团队的相互学习和提高。

Reviewer的态度：它们对Code Review的态度很大程度上决定了Code Review的效果。常见以下几种情况：
漠不关心：这种态度的来源主要是觉得代码不是自己写的，也不用负什么责任，对代码走查的实际含义理解不清。想糊弄过去凑个人数结束。
藐视别人的代码：这种心态长见于团队中技术水平较高的成员中，在别人讲解代码的时候总觉得这个功能很容易实现，自己知道不用听别人讲了。这种人缺乏对团队的责任感，和对团队成员成果的尊重。
批评者：这类人对Code Review的目的是什么认识不清，总以为代码走查就是找别人的错，吊难别人。这种容易忽视别人代码设计中的优点。做为程序员每个人都有自负的一面，这样在Code Review时常常会出现Code Review就是找别人错误的错误认识。

Code Review 的实施

一、Code Review 角色分类
    1.Author：被Review对象的作者。
    2.moderator：一般由团队中开发经验丰富的人担任。
    3.Recorder：主要用于记录在整个代码Review中情况。
    4.Reader (may be the same person as Author or leader)
    5.Other reviewers：团队中的其它成员，但是一般不要人太多，因为对于一个讨论会议一来说一般要将参加会议的人控制在7人以内为最佳，这样这个会议才是可控的。
    以上这些角色的职能会在Code Review中的不阶段而发生变化。

 

二、Code Review的流程及其角色在不同阶段的任务

上图显示了整个Code Review活动流程情况，一般在一个Code Review活动会中Planning,Preparation,Meeting,Rework&Verfication是必须的，而Overview阶段会随着Review对象的不同而不同，对于一些Review工作大量的活动这个阶段是必须的，下面将详细描述每个阶段的任务，以及各个角色在相对应阶段的责任。

1.Planning:

这个阶段主要是对各个角色人员的确定以及确定所Review的对象是否已经达到能够被Review的阶段，这样以防止代码在仍有很大 问题的情况下进行Review而导致Review的整体效率太低。还有对整个Review过程所以经历的时间段有一个大体的划分。在这一阶段首先由Author确定谁来当本次Review的moderator（一般moderator只能从团队中有限的几个人内挑选，并不是每个人都可以充当这个角色的。）然后再邀请别人充当本次Review的Recoder，Other reviewers；
这个阶段各个角色的主要任务是：
Author：对整个Review过程制定计划，确定参加这次Rewview人员，为这些成员分发要Review的材料。
moderator：对整个要Review的对象进行分析查看是否达到能够开始Code Review的要求。

2.Overview:
对于大量的东西要Review的项目，或者大部分参与Review的人对要Review的东西都不是很熟悉的情况下。由Author开招开一个简短的站会整体解决一下所要Review的东西。

3.Preparation:

在这个阶段，所有参与的reviewers对所以review的东西各自进行走读，然后记录并提交发现的问题，然后由Author和moderator共同对reviewers所发现的问题进行汇总，分类，甄别。之后根据汇总上来的问题来进一步判断是否适合招开Review会议。如果汇总上来的问题比较多，比较严重则说明所要Reivew的文件尚未真正达到要求，则取消本次活动。由Author重新开发。如果发现的问题不是很多，则按时招开Review Meeting.

 

这个阶段各个角色的主要任务是：
reviewers:对所要Review的对象各自先进行走读，然后提交各自发现的问题。
moderator和Author：对reviewers提交上来的问题进行汇总总结查看是否符合Review的条件。

4.meeting:

meeting做为整个review的核心和关键环节其主要任务是首先由Author主持对汇总上来的问题，逐个的分析然后给出自己的判断，是接受reviewers还是不接受reviewers提出的问题。对于有分歧的问题进行讨论，如果还有分歧则由moderator决定这个问题是否要改怎么改。在将所有汇总上来的问题分析完后，再由Author带着所有reviewers对代码进行走读。然后进一步分析和讨论代码中的问题。

 

这个阶段各个角色的主要任务是：
Author：逐个分析汇总上来的问题，并给出自己的分析。带领所有reviewers对代码进行走读；
moderator：分析判断Author对问题的分析判断是否合理，在关键时刻给出分歧问题的处理意见；
reviewers：讨论分析之前提出的问题，对代码进行集体的重新走读，以发现更多的问题；
Recorder：对整个Code Review进行记录，包括发现的问题以及问题的整改意见。

 

5.Rework&Verification:

这个阶段主要是Author对整个Review过程提出的问题进行整改，然后提交由moderator对整个整改的情况进行评估。

总结：
通过对Code Review中的成员进行角色分工，从而赋予他们一定的职责，这样就能很好的提高他们的责任感从而大大提高代码走查的效率。