我们该如何做好Code Review?

标签: code 代码规范 代码优化 | 发表时间:2017-02-15 17:20 | 作者:罗拙呓
出处:https://segmentfault.com/blogs

我们该如何做好Code Review?

引言

午后的阳光,静静地照在你的脸上。这时候配上一杯82年的java,脑子一片灵光闪过,呃......上午刚写完需求,下午好像没什么事了,不如看看自己写的代码?至此,一场Code Review也就拉开序幕了。

82年的java

前言

Code Review,即代码审查,是指对计算机源代码系统化地审查,常用软件同行评审的方式进行,其目的是在找出及修正在软件开发初期未发现的错误,提升软件质量及开发者的技术。代码审查以不同的形式进行,例如结对编程、非正式的看过整个代码,或是正式的软件检查。 [1]

配对review(Mutual Review)

在我们项目组的code review中,制定了A童鞋与B童鞋的一对一review关系,“配对”成功后,这两位童鞋的代码负责相互review对方的代码,这样也形成了责任关系,可能这里有些人会表示并不赞同这种“强制”的责任制,更喜欢随意的工作方式。但是我们在实际中发现,如果不采取一对一的这种方式,很容易造成漏掉review某些童鞋代码。当然,在相互review之后,还可以继续对其他同事代码进行review,这样既确保了完备性,也保证了多样性。

流程和步骤如下:
Owner(被review的童鞋),Reviewer(执行代码review的童鞋)。

  • Reviewer对Owner的代码进行review,针对某个缺陷代码提出review,格式如下:

    @Override
    protected void onDestroy() {
        super.onDestroy();
        BitmapCache.getDefault().clear(true, false);
        BitmapCache.getDefault().close();
        //TODO review by xxx 2016/12/28 最好不要显示调用这个方法,如果必须要进行垃圾回收建议与runFinalizationSync(),否则调用可能不起作用。
        System.gc();
    }
  • Owner修改之后,并不要删除todo,而是由对应的Reviewer验证之后来删除,所以Owner修改完代码之后,格式如下:

    @Override
    protected void onDestroy() {
        super.onDestroy();
        BitmapCache.getDefault().clear(true, false);
        BitmapCache.getDefault().close();
        //TODO review by xxx 2016/12/28 最好不要显示调用这个方法,如果必须要进行垃圾回收建议与runFinalizationSync(),否则调用可能不起作用。
        // FIX by xxx: 2017/1/11 
    }
  • Owner对已经修复完的问题进行再次Review,验证通过之后可以删除上述的todo及fix,如验证失败则继续补充相应的TODO。

    @Override
    protected void onDestroy() {
        super.onDestroy();
        BitmapCache.getDefault().clear(true, false);
        BitmapCache.getDefault().close();

至此,Mutual Review也就顺利完成,这项工作我也把它称为Daily Review,因为这项review属于日常性,长期性的工作,从我们项目组来看,这项工作发现大多数缺陷代码。那么既然如此,为什么还需要Review Meeting呢?主要考虑有如下几点:

  1. Mutal Review的结果不能达成一致时,也就是说两个童鞋谁也不认同谁,这样就需要大家一起讨论来定夺应该怎么修改。

  2. Code Review会议能够集思广益,往往经过讨论之后能得到问题的最优解或次优解。

  3. Code Review会议使得各个人员之间能够面对面的进行交流,比起Mutual Review能对需要修改的点进行更细节的讨论,并且沟通效率更高。

代码评审会议(Review Meeting)

review meeting
代码评审会议一般流程如下:

  1. 每期版本迭代上线前至少进行一次,且最好应在上线前一周做完,最少也得提前三天,因为需要预留给测试时间进行review修改后的测试。

  2. 每次会议时间不宜过长,如讨论内容较多可分次举行。

  3. 在一次会议过程中,每位开发童鞋轮流对自己已经在代码中写过//TODO review by xxx 的地方进行讲解。讲解每处review的原因,其他童鞋可以进行讨论,是否有修改的必要?有没有更好地实现方式?是否需要将该案例加入到编码规范中?等等。

  4. 讨论结束后,总结会议中讨论的结果,并综合考虑修改的工作量与上线前剩余的时间,最终决定是否在上线前修改完成,还是可以考虑上线后下个版本进行修改。

结语

经过理论及实践表明,定期进行Code Review有如下几点好处:

  1. 能够学习他人代码,能够开阔思路,并且提升代码健壮性,改掉边界条件考虑不周的情况。

  2. 对于测试同学没有能够测试到的bug提前进行修复,降低线上bug及crash率。

  3. 在code review会议中集思广益,促进团队成员交流,有助于营造团结协作的团队氛围。

说了这么多,如果你不想看或者实在做不到的话只能送你一句话了。

就是干

文末福利

本人目前在网易搬砖,如果想要挪挪地方, 请猛戳此处,选好部门及岗位以后,欢迎投简历给我(changan_luo@163.com),我来帮您内推。

最后欢迎拍砖,说得不好的地方欢迎交流~

如果感兴趣的话希望给民工加个收藏,谢谢~

相关 [code review] 推荐:

聊聊Code Review

- - 梦想风暴
hopesfish评论《 那一点的调用》时,问了一个关于Code Review的问题:. 想请教一下,TW的筒子是如何做code reivew或者鼓励客户做code review的. 我在翻阅博主的帖子的时候,似乎对这块没有特别强调,而是更多偏重于TDD,我觉得TDD的问题是一碰到没有责任心的程序猿,就很容易流于形式了.

Java Code Review清单

- - ImportNew
使用可以表达实际意图(Intention-Revealing)的名称. DRY(Don’t Repeat Yourself)原则,(拒绝重复). 用代码来解释自己的做法(译者注:即代码注释). *参考自: http://techbus.safaribooksonline.com/book/software-engineering-and-development/agile-development/9780136083238.

我的code review规则

- vento - 我的宝贝孙秀楠 ﹣C++, Lua, 大连,程序员
1) 是否有语法错误,编译错误,编译警告. 做法:下载最新代码,将编译警告级别提升到最高,检查output信息. 2)是否符合需求,完成requirement文档要求的内容,不能多,也不能少. 注意:即使发现有问题代码,如果与需求关联不大,不要涉及. 应该让每次enhancement和bug fix最简洁,牵涉范围最小,影响到组件最少.

Code Review那些事儿

- - 非技术 - ITeye博客
       曾经有一段 垃圾代码放在我的面前,我没有拒绝,等我真正开始接手的时候我才后悔莫及,程序员最痛苦的事莫过于此. ---------改编于周星星的经典台词.       虽然有点夸张,但编码界确实大大存在这种情况,每当接手别人的代码,都有一种想重新写一遍的感觉,等到别人再来接手你的代码时,同样的感觉.

代码审查(Code Review)清单

- - 博客 - 伯乐在线
代码审查可以帮助提高代码质量,避免由于代码习惯而造成的 bug. 下面列出的这些要点因该可以作为大部分代码审查的指导,如果是 Java 应用的话,这些建议应该被视作最佳实践. Javadoc 应该在每一个类和方法中添加. 如果是修复某个 bug,应该添加 bug ID. 走捷径的方法或者复杂的逻辑要有解释.

从Code Review 谈如何做技术

- - 酷 壳 - CoolShell.cn
(这篇文章缘由我的微博,我想多说一些,有些杂乱,想到哪写到哪). 这两天,在微博上表达了一下Code Review的重要性. 因为翻看了阿里内部的Review Board上的记录,从上面发现Code Review做得好的是一些比较偏技术的团队,而偏业务的技术团队基本上没有看到Code Review的记录.

我们该如何做好Code Review?

- - SegmentFault 最新的文章
我们该如何做好Code Review?. 午后的阳光,静静地照在你的脸上. 这时候配上一杯82年的java,脑子一片灵光闪过,呃......上午刚写完需求,下午好像没什么事了,不如看看自己写的代码. 至此,一场Code Review也就拉开序幕了. Code Review,即代码审查,是指对计算机源代码系统化地审查,常用软件同行评审的方式进行,其目的是在找出及修正在软件开发初期未发现的错误,提升软件质量及开发者的技术.

测试技术中CODE REVIEW的重要性

- - CSDN博客推荐文章
        [近期关注App自动化测试,欢迎交流,本博客文章版权归作者所有,转载请联系]     .         最近有网上的朋友向我咨询作为测试员是否应该跳槽,   首先我觉得应该向大家介绍一下什么是测试工程师,  什么是测试员,   在国内的一些中型企业并没有特别的指明.   这里测试工程师主要指测试开发工程师, 主要包括两类,  其一是测试软件开发的工程师,  其二是自动化测试脚本开发和维护的工程师,   而测试员主要指单纯编写/管理测试用例,  或是手工测试人员, 一些国内的大中型网络视频公司仍然在用纯手工测试,我感觉到很汗颜.

谈一下我们是如何开展code review的

- - 文章 – 伯乐在线
众所周知,代码审查是软件开发过程中十分重要的环节,楼主结合自己的实际工作经验,和大家分享一下在实际工作中代码审查是如何开展的. 笔者水平有限,若有错误和纰漏,还请大家指正. 我想不通公司不同部门对代码审查这项工作的重视程度还是不一样的,对于代码审查的阻力总结了以下几点:. 国内的整体环境,国内的公司,尤其是互联网公司,讲究速度致上,软件开发的迭代周期周期短,速度快,因为竞争太大,开发的产品要求快速上线,对代码审查不是很重视,先上线,出了问题再解决.