我所理解的代码评审

最近组内一直在推行代码评审，到现在也进行了约10期了，虽然经验还很少，但是也应该总结反思一下。这里总结一下这个过程中的一些东西，算是一个整理贴。以下纯属个人见解，可能有的观点并不科学，仅供参考。

 

一.为什么要进行代码评审？

凡事都有其目的性，很多时候，我们做一件事情，但是做着做着，到后面发现已经偏离了初衷。有鉴于此，首先得明确目的性。那么代码评审的目的是什么呢？个人觉得，应该有如下这几个目的：  

1.过滤肉眼可见的表面问题

这应该是最基础的目的，通过群众的眼睛，找出一些显而易见的代码层面的问题，比如明显的逻辑错误、缺少了异常处理、可读性差、不符合编码规范等等。不过这也仅限于一些表面问题，因为真正业务相关的东西，仅仅靠看代码是难以识别出来的，得通过测试来检测。

2.提升技能水平

学习别人的优缺点，将他人的知识转化为自己的经验与技能。

3.交流

知道别人最近在干嘛。

4.提升责任心，严谨性

讲解者既然将代码拿出来让大家评审，肯定是经过了一番思考检查的。这也能从侧面提升责任心与严谨性。

5.“讲”出来，梳理思路，加深项目理解

有的东西，想想好像很清楚，但是真正讲出来，就会发现很多细节上的问题。

 

二.如何进行代码评审？

很多事情都是说说容易，但是做起来难，特别是那些需要持续进行的事情。代码评审是一项长期的工作，如果没有一个好的实现方案，就很容易夭折。

如何进行代码评审呢？

1.印象中的代码评审

可能大部分人印象中应该是这样的：

同事A拿出一段代码，然后大家围成一个圈，抱着“大家来找茬”的心态，对其狂轰滥炸，哪怕没有什么问题，也要从一些细枝末节上找点东西来说(只要你愿意，总能找到)，似乎自己不讲点什么，不批判一番，就没有加入进来。

中枪了么？

2.被评审者的期望

让我们站在被评审者的角度看看他是怎么想的：

(1)我经过深思熟虑，准备了这段代码

(2)我希望别人能够发现其中的亮点

(3)我希望得到别人的赞同

(4)我也希望代码中的错误得到指正，但是最好能温和一点

而上述的评审方式，无疑是和他的期望对着干:)，换了是你，下次你还会继续拿代码出来讲么？

3.我们应该这样

所以，我们应该这样：

(1)对于别人的代码和语言，表示足够的重视。千万不要在别人展示代码的时候，表示漠不关心(打瞌睡、玩手机、讲悄悄话，这些举动的杀伤力远比你想象的大)。一个良好的倾听者会给其带来莫大的动力。

(2)别单纯的找茬，别人把代码拿出来评审，一方面是借助大家的力量帮其发现问题，另一方面，何尝不是你的一个学习机会？你应该在发现别人不足的同时，也要去发现其优点。如果没有什么发现，那么可以保持沉默，不用说什么，只需静静观察即可。其实我觉得“代码评审”这个名称不好，叫做“代码交流”更贴切，这是一个平等的交流活动，而非一个批斗会。

(3)不要吝啬赞扬的话语。如果发现了某个地方写得不错，立刻大声的将其讲出来。认同与成就感是你能给于别人最大的奖励。

(4)如果发现对方代码存在问题，不要直接持否定态度，可以先问问他为什么这样写，是否有其他的原因。

 

三.一些注意事项

代码评审具体的实施，因团队而异，不过有一些问题应该是类似的。

1.虎头蛇尾

长期活动常常存在虎头蛇尾的情况，前面激情澎湃的弄几期，接着后继乏力，最后不了了之。对于这种情况，我的感觉是：

(1)要有“肇事者”

以前看过一篇文章，说大致存在三种人，具体分类记不清楚了，只记得其中一种是“肇事者”，也就是非常积极的组织者。尤其是长期活动，更需要一个能坚持的“肇事者”，在氛围形成之前，积极带动其他人参与进来。比如平时组内哪些人比较活跃的，那么可以让他们在前期多参与一下，提高组内的活跃度，营造一种“热火朝天”的现象。人都有随大流的心理，当看见别人一个二个都在做相同的事情时，自己也就会下意识的跟着做。当然，你自己也得准备一下，如果某期大家都没什么东西讲，你就得作为一个“备胎”上场了。每一次代码评审前，我都会在U盘中准备一份资料，确保出现这种情况时，自己能顶上。

(2)及时调整

类似这样的活动，常常因为囿于形式，而最后让大家产生抵触情绪，难以持续下去。我觉得只要明确目的，具体的形式内容都是次要的，可以根据不同时期，做出不同的改变。

2.拿出一大堆代码

我们常常说，要站在对方的角度去考虑问题，因此，千万不要拿出一大堆代码来做评审。谁愿意看这么多密密麻麻的代码呢？代码过多会直接耗掉读者的耐心。网上比较科学的说法是评审的代码长度尽量不要超过400行，如果代码过长，可以通过口述的方式，让大家了解业务，然后只查看具体某一个模块的实现。

3.缺乏时间控制

我们以往组织了不少活动，大都无疾而终。现在想想，没有控制时长应该是一个原因，常常一个会议搞到两三个小时。一次两次还好，如果每一次，都拖得很长，到后面就会成为大家的一个负担。心都不在这里了，哪里还有效率可言。因此建议制定一个上限时间值，比如半小时或者一小时。

4.听完收工

千万不要只带着两只耳朵来评审，哪怕会上讨论得再激烈，总结的东西再多，下去后没有后续动作，也是一场空谈，同样的问题势必还会再次出现。建议:

(1)随身带个笔记本，将你觉得有用的信息记录下来，会议结束后整理一下，作为今后的参考。笔记这东西，用得不好就是一张纸，用得好则往往会给你带来惊喜。

(2)最好会议结束的当天，立刻将你觉得需要改进的地方修正过来，不要等到第二天。根据个人经验，第二天从来没有到来过:)

(3)必须有检查这个环节。比如会议上发现的一些问题，在下次会议上，可以在开头花个几分钟查看下修改后的代码。目前我们还没有这个环节，基本上是通过自己主动去阅读组员的代码来检查。