代码评审（Code Review）

      最近一直在看《Making Software》一书。提及这本书不是因为它带来了技术上的冲击，而是因为它在提醒我思考一些东西。

      代码评审使我从学校走到社会感觉最大的一个变化之一。在学校做项目的时候是埋头写代码，到了公司就完全不一样了，代码在具有更多商业价值的同时也需要更多的质量保证。而代码评审时一个重要的保证。通过阅读并结合自己的经历谈谈几点体会：

1 心态
这是代码审查时候最需要调整的一方面。我第一次做代码审查的时候很紧张，也很没有把握。过程中每被指出一个问题都感觉有点无地自容。原先的那种技术优越感一下子被打碎了，剩下的就是一种暗暗地痛。随着时间的推移，我开始慢慢适应了代码评审，不仅仅是被评审，也积极地参与到评审中。不断发现问题的同时，也不断欣赏优点。

2 自查
如下是Cisco®的一份比较了300份有事先检查和300份事先未检查的情况下进行的代码评审的结果对比研究数据。一个简单的自检是否就足够是一个仁者见仁的问题。但是很多缺陷都可以在自检中被发现，当然也会留下很多需要在审查中由其他人提出。

3 时间
在有些公司中代码评审是代码提交前一个必走的流程。这种情况下，如果在期限之前没有留足审查时间，代码评审就显得很被迫，有时候为了按时完成需要长时间连续评审。比如长达几个小时的评审不仅无法得到预期成效，而且容易照成参与人员的评审疲劳。

4 语言
一个团队中的成员一般在性格方面差异很多，体现在语言上就是有的人彬彬有礼，“这个地方这样是不是会比较合理些呢？”。有的人是开门见山，“这里应该问题”。还有的是咄咄逼人，“这里怎么这样处理啊! Blah blah不就得了”。当然考虑到被评审人员的心态因素，语言方面就应该尽量柔和。

5 集体沉默
在代码评审中比硝烟更可怕的是集体沉默。但大家对软件失去热情的时候，评审就成为了一种过场。在规定的时间开始，在规定的时间结束，时间就在被评审者不断拖动的一屏屏代码中流逝。集体沉默很可能意味着团队中的一种相互地不懈，也可能源于大家之前的某一次激烈的争辩后的一无所获，更可能是因为大家认定自己提到的东西很难被接受，即使接受了也很难被执行。在一段时间内，我就有这样的一种心态，因为那时由于制度和执行上的缺陷，很多评审中提到的问题根本没有得到修正就直接成为了发布代码，感觉自己弄得一身灰的同时没有带有任何价值。

6 大拿
评审比较理想让大家可以感受到一种平等对话的氛围。相关方面的技术专家，技术大牛和程序高手并不能保证评审的成效。需要地只是他们适度地参与，在关键时候给予指导和分析，而不是成为主角。这不仅造成其他参与者没有机会发表自己意见，更容易给他们造成心里压力从而影响参与积极性。