Code 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的效果大大折扣，但上面的形式也有好处，它们都更开发更利于交流。第三种形式是个人最好的一种形式，将在一下篇文章中详细介绍这一形式。