代码评审(Code Review)
代码评审(Code Review)
最近一直在看《Making Software》一书。提及这本书不是因为它带来了技术上的冲击,而是因为它在提醒我思考一些东西。
代码评审使我从学校走到社会感觉最大的一个变化之一。在学校做项目的时候是埋头写代码,到了公司就完全不一样了,代码在具有更多商业价值的同时也需要更多的质量保证。而代码评审时一个重要的保证。通过阅读并结合自己的经历谈谈几点体会:
1 心态
这是代码审查时候最需要调整的一方面。我第一次做代码审查的时候很紧张,也很没有把握。过程中每被指出一个问题都感觉有点无地自容。原先的那种技术优越感一下子被打碎了,剩下的就是一种暗暗地痛。随着时间的推移,我开始慢慢适应了代码评审,不仅仅是被评审,也积极地参与到评审中。不断发现问题的同时,也不断欣赏优点。
2 自查
如下是Cisco®的一份比较了300份有事先检查和300份事先未检查的情况下进行的代码评审的结果对比研究数据。一个简单的自检是否就足够是一个仁者见仁的问题。但是很多缺陷都可以在自检中被发现,当然也会留下很多需要在审查中由其他人提出。
3 时间
在有些公司中代码评审是代码提交前一个必走的流程。这种情况下,如果在期限之前没有留足审查时间,代码评审就显得很*,有时候为了按时完成需要长时间连续评审。比如长达几个小时的评审不仅无法得到预期成效,而且容易照成参与人员的评审疲劳。
4 语言
一个团队中的成员一般在性格方面差异很多,体现在语言上就是有的人彬彬有礼,“这个地方这样是不是会比较合理些呢?”。有的人是开门见山,“这里应该问题”。还有的是咄咄逼人,“这里怎么这样处理啊! Blah blah不就得了”。当然考虑到被评审人员的心态因素,语言方面就应该尽量柔和。
5 集体沉默
在代码评审中比硝烟更可怕的是集体沉默。但大家对软件失去热情的时候,评审就成为了一种过场。在规定的时间开始,在规定的时间结束,时间就在被评审者不断拖动的一屏屏代码中流逝。集体沉默很可能意味着团队中的一种相互地不懈,也可能源于大家之前的某一次激烈的争辩后的一无所获,更可能是因为大家认定自己提到的东西很难被接受,即使接受了也很难被执行。在一段时间内,我就有这样的一种心态,因为那时由于制度和执行上的缺陷,很多评审中提到的问题根本没有得到修正就直接成为了发布代码,感觉自己弄得一身灰的同时没有带有任何价值。
6 大拿
评审比较理想让大家可以感受到一种平等对话的氛围。相关方面的技术专家,技术大牛和程序高手并不能保证评审的成效。需要地只是他们适度地参与,在关键时候给予指导和分析,而不是成为主角。这不仅造成其他参与者没有机会发表自己意见,更容易给他们造成心里压力从而影响参与积极性。
转载于:https://blog.51cto.com/bj007/427753