提醒:本文发表于 2014-03-13 18:58:03,文中所描述的信息可能已发生改变,请仅作参考使用。

不要有任何怀疑,一个优秀的Code Reviewer就是你自己,确保自己有一颗Code Reviewer的心,然后努力提高自己的技术。当你比别人牛逼时分享你的知识,当别人比你牛逼时倾听他们的分享。

这篇文章,记录了我在组织团队Code Review过程中的感慨和困惑。


我处在的是一个业务团队,业务团队一个最大的特点就是:大家都在忙着做业务开发,没有心思顾及代码质量、单元测试、自动化构建等等问题。(这算是自黑吗?)

当团队和产品慢慢趋向于稳定状态,当大家有了业务开发之外的空闲时间之后,一些高大上的东西就会被团队成员更多的提及,如:开发文档、编码规范、代码质量、代码注释、单元测试、自动化构建等等,Code Review就是这种状态下的一个产物。

最初,就像钻木取火一样,我是团队中第一个萌生做Code Review这件事的人,有了这个想法之后,就动手开始做了。

在第一次Code Review过程中,遇到的第一个问题就是没有同盟者,虽然团队成员有6人,但是大家对Code Review并没有什么概念,试图影响其他人并重视Code Review是十分困难的,在代码注释、文档、测试用例十分匮乏的业务团队,可想而知大家对代码质量重视程度如何。因为团队规模比较小,所以,我设定所有人一起参加,大家每周专门拿出一段时间来Code Review。

刚开始做Code Review时,现场气氛十分沉闷,我只能尽量挑出一些代码中的基础与业务无关的问题,这些问题主要与低质量代码缺陷和编码规范相关,大家也就有了几分兴趣,至少能专心的倾听。

一段时间之后,Code Review渐渐涌现出一些积极分子,他们成为了我拉拢的对象,有了支持者之后,我轻松了很多。一些明显的代码缺陷大家不会再犯,代码质量提高了不少,并且有人与你一起发觉缺陷。Code Review的内容也从基础问题延伸到了编码设计和业务逻辑上。

虽然Code Review讨论的问题领域扩大了,但是新的问题也一并出现。审查业务逻辑缺陷是我认为Code Review中最难的一部分,因为这需要你对这块业务有足够的理解,才可能发觉业务代码中存在的缺陷。对于业务的不相关者来说,大家并不没有时间和精力来审查你的业务逻辑写得是否正确并合理。所以,我会把业务代码上发现的设计或逻辑缺陷泛化,将问题套用到一些通用的业务场景,使大家能在自己的业务模块中能找到一定的参照对象,这样大家在理解的时候就容易很多。

最后,也就是现在,是我认为最艰难的一个阶段,如何建立Code Review的团队文化?如何让Code Reivew制度化、标准化,并一直的保持下去?这是我在思考的两个问题。

总结,Code Review的积极作用:

  • 能大幅提高团队成员对基础知识的掌握程度,对编码能力有直接促进作用;
  • 能让团队成员在准从的编码规范上保持一致,规范化大家的代码、文档和注释等;
  • 能很快的将新技术推广到团队中,并使大家快速掌握使用经验和技巧;
  • 能给大家提供一个团队业务交流的机会;

--EOF-- 最后更新时间:2015-06-17 20:55:29

本文链接:http://www.maxzhang.com/2014/03/一个Code-Reviewer的感慨和困惑/