徐彬耀：软件测试中的CodeReview
Code Review 做软件开发的时间转眼也有三年有余，所在的团队也使用了各种各样的代码质量控制方法，个人觉得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做为当前常见的一种代码质量和团队技术交流的手段常见以下几种形
式：Peer Review：这种形式是从结对编程中抽象出来的简化版。主要由两个人完成代码走查工作，一个是代码的编写者，一个是对代码的查看者。先由代码编写者向代码走查者对代码进行简单的讲解，然后由代码查看者提出代码需要改进的地方。之后由编写者修改代码。Peers Review:这种形式是上面Peer Review的一个进化版增加了代码查看者的数量，通过引入更多的眼睛来更有效的发现代码存在的问题，同时使更多的人了解某一功能的解决方法，也扩大了对该功能的解决方法的讨论的范围。
分角色的多对一Code Review:和Peers Review不同的地方在于对Peers进行了简单的分工,一般分为这样几个角色：Author，moderator，Recorder，Other reviewers。由Author准备Code Review时所需的材料并对材料进行简单的讲解，同时由moderator 检查所要Code Review的材料是否有效，同时决定代码走查时的一个整体的走势例如不能让会议陷入漫无目的的讨论中去，同时在代码走查后负责检查对代码走查成果的修改工作是否到位。Recorder记录代码走查过程中发现的问题以上三种形式，其中前两种形式由于查看者的角色没有细分，在Code Review的时候容易流于形式，从而使Code Review的效果大大折扣，但上面的形式也有好处，它们都更开发更利于交流。第三种形式是个人最好的一种形式，将在一下篇文章中详细介绍这一形式。
许多年前农村土地承包责任制的出现，使之大农民的角色发生了根本性的改变，从而迎来了粮食产量和农民很生活的巨大改善。同时在Code Rivew 这一个群体活动中，让其有效运行起来一个最有效的方法就是分角色同时对某一角色赋予一定的责任。下面就对在我们团体中分角色的Code Review及其流程进行一个简单的讲解，同时也想和广大软件同仁们一起交流一下关于CodeReview的一些观点和看法。因为是本公司的方法所以也会有不足之处，欢迎讨论。
一、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工作大量的活动这个阶段是必须的，下面将详细描述每个阶段的任务，以及各个角色在相对应阶段的责任。