代码审查

前言
说起代码审查(CodeReview)大家应该都不陌生,可以说代码审查的有效性是不可否认的,但相信大部分实施或参与过代码审查的人都能体会到一种想说爱你不容易的感觉,特别是对于一些中小型的创业公司,代码审查往往更难以落到实处,就算是实施了一段时间也往往流于形式最后不了了之。
我们团队从去年就像开始实施代码审查,但效果不尽如人意,中间中断的时间比执行的时间还长,在最近的回顾会上代码审查的必要性问题又被提了上来,反思后决定再仔细调研一下成熟的组织是如何进行代码审查的,于是就有了这篇文章。
什么是代码审查
代码评审也称代码复查,是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。大多在开发完成后,提交到正式仓库前进行。

代码审查的意义
1.提高代码质量,发现65%~85%的bug
2.知识分享,有利于知识的传播和新人的成长
3.代码审查有利于促进高效沟通,构建技术氛围
4.增加团队代码的可维护性和抗风险能力,同一份代码至少有2人熟悉(作者和审查者)
代码审查案例
Google
说到Google和代码审查就不得不说Google的代码审查价值观:
The biggest thing that makes Google’s code so good is simple: code review.That’s not specific to Google – it’s widely recognized as a good idea, and a lot of people do it. But I’ve never seen another large company where it was such a universal. At Google, no code, for any product, for any project, gets checked in until it gets a positive review.
落地措施
1.所有的代码都要经过代码审查才能提交
2.每个工程或模块都有一系列的所有者,所有者具有继承性(模块->子模块),至少一个所有者是一个提交的作何或是reviewer.
3.任何一个Google员工都可以对代码进行review
4.通过邮件或web系统来进行交互
5.代码审查通过Google内部的代码审查工具完成
其他的优秀代码审查的案例都跟Google大同小异,甚至都是Google系的公司,所以在这里就不多赘述了。
我们的代码审查
本文开头就提到我们的代码审查并不成功,为啥现在要在这提出来呢,主要是希望大家吸取教训,以避免重复我们的弯路。
以下是基本情况:
1.我们的代码审查是通过UpSource页面进行
2.时间是定在每天下班前的半小时
3.我们规定重要模块进行代码审查
4.代码审查全靠自觉没有采用Git的PR模式进行源码的管理
5.代码审查在电视投影进行,但每次进行都需要移动电视和连接计算机
结果如下:
1.代码审查不积极,经常没人进行代码审查
2.只有团队领导在的时候进行代码审查,一旦推动者出差代码审查就取消
3.就算进行代码审查,没有严格的定义审查的标准,也是指定的人才会进行代码审查
4.代码审查安排的时间过晚,经常因为意外情况中断或取消代码审查。
5.团队成员并不能理解审查的必要性
6.团队也多次讨论过代码审查的问题,得出的结论无外乎1)项目进度压力大,代码审查可能影响进度;)大多数代码变更都十分简单,没有必要也不值得代码审查
最终结果:
1.代码审查断断续续
2.每次改进都会提到代码审查的实用化,但没有缺乏有效的落地措施
代码审查的工具
Gerrit
Gerrit,一种免费、开放源代码的代码审查软件,使用网页界面。利用网页浏览器,同一个团队的软件程序员,可以相互审阅彼此修改后的程序代码,决定是否能够提交,退回或者继续修改。
UpSource
upsource是JetBrains公司在2014年推出的一款通过浏览器查看代码达到团队协作功能的工具。它适用于需要解决对代码做review以及统计开发人员对代码贡献等问题的团队。(upsource当前面向10用户以内的开发团队是免费的,10用户以上需要购买)
 UpSource是支持Intellij IDEA插件的,所以配置好的话,再IDE中就可以进行代码审查了,非常方便。
除了标准的代码审查功能,还提供一些简单使用的统计功能。
小型团队比较推荐
Review Board
一个开源的、基于web的代码和文档审查工具,用于帮助公司、开源项目和其他组织保持代码的高质量,而且bug数量也会比较低。请注意,这是审查代码和文档的。这意味着你可以用它来审查任何事情。简单地将一个文件拖放到一个评审请求中,然后任何人都可以在它上面留下注释。例如,将它用于日志文件、控制台输出,甚至可以对UI和图形进行评论和评论。
提供差异查看器(文件比较),它允许将代码扩展到最近的函数或类,最近的代码更改,或者每次20行。它还提供了简单的注释、基于web的界面和命令行工具来简化审查请求提交过程。指示板提供了对所有审阅请求的最新概述
总结
成功代码审查的实施建议,也是我们准备调整的措施:

强有力的组织推动 (组织发文)
统一的编码规范 (阿里的Java编程规范)
顺手的工具(采用IDE集成的模式)
科学的代码管理模式(Git的PR模式,非review不能提交)
合适的奖惩措施(优秀reviewer将得到适当的奖励)
高频小块的进行代码审查(提前到每天下班前一个班小时进行)

对于代码审查来说有句话非常合适,现在或是永远,进行代码审查就要每天进行,这样团队就会产生惯性,不再依赖推动者。
PS:工具不是代码审查的关键点,现阶段再好用的IDE也不能自动生成代码,重要的实施的人,对人和团队的引导是实施有效代码审查的保证
---------------------
作者:zhaoenweiex 


点击关闭
  • CMMI认证客服

    CMMI3认证客服

    CMMI咨询

    CMMI4认证