我们该如何做好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会议中集思广益,促进团队成员交流,有助于营造团结协作的团队氛围。

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

就是干

文末福利

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

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

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

相关 [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

- - IT瘾-dev
一、Code Review的好处. 想要做好Code Review,必须让参与的工程师充分认识到Code Review的好处. 无论是高手云集的架构师团队,还是以CURD为主的业务开发团队,大家的技术能力、经验都是有差异的. 通过Code Review,对于同样的功能实现,有经验的工程师可以给经验尚浅的工程师提供合理的优化建议.

测试技术中CODE REVIEW的重要性

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