Code Review那些事儿

标签: code review | 发表时间:2017-01-08 01:46 | 作者:jxauwxj
出处:http://www.iteye.com

       曾经有一段 垃圾代码放在我的面前,我没有拒绝,等我真正开始接手的时候我才后悔莫及,程序员最痛苦的事莫过于此!---------改编于周星星的经典台词。 酷

 

      虽然有点夸张,但编码界确实大大存在这种情况,每当接手别人的代码,都有一种想重新写一遍的感觉,等到别人再来接手你的代码时,同样的感觉。。。为什么会有这种现象存在?因为没有Code Review

 

一。前言

       Code Review中文应该译作"代码审查"或是"代码评审",也叫代码QC,这是一个流程,当开发人员写好代码后,需要让别人来review一下代码,这是一种有效发现BUG的方法。review之后,可以发现代码的风格、逻辑、思路等问题。然后改进代码,提高代码质量。因为这是代码刚刚出炉的时候,所以,这也是代码调整、代码修改、代码重构的最佳时候。所以,Code Review是编码实现中相当重要的一个环节。

 

二。Code Review的内容

1.编程素养

       见码如见人,代码风格在一定程度上反应一个程序员的能力和素养,如代码风格、注释、变量的命名、缩进、初始值、方法的长度、流是否关闭、连接是否关闭

 

2.业务逻辑

  代码实现的过程,就是对需求理解的一种复现,如果业务逻辑都错了,代码写得再漂亮、再牛B也是枉然

 

3.架构设计

      业务逻辑实现了,只能给60分,代码是否具有高内聚、松耦合、可扩展的特性?是否合理设计模式?

 

4.单元测试

      没有经过单元测试的代码,不是好代码。大多数开发人员认为,测试的环境是测试人员做的事,不然要测试人员做甚?其实不然。

      单元测试是一种无价的文档,它是展示方法或类如何使用的最佳文档。这份文档是可编译、可运行的,并且它保持最新,永远与代码同步。

      单元测试也是架构设计的一部分,迫使我们在设计时把代码设计成可调用、可测试,从而降低代码的耦合。自动化的单元测试避免了代码出现回归,编写完成之后,可以随时随地的快速运行测试。

 

5.性能

       对数据结构的选择和设置是否合适?

       是否采用通用的线程池、对象池模块等cache技术以提高性能?

       是否选择合适的IO类或采用良好的方法以提高性能?

       同步方法的使用是否得当,是否过度使用?

 

6.安全

       是否有后门?

       如果是web页面,是否有csrf、xss漏洞?

       是否明文存储了用户名密码?

       日志中是否打印了敏感信息?

 

三。review的方式

1.借助软件,软件请看第四点。

      建议开发人员都安装这些插件,发现问题时及时就改了

 

2.项目负责人或架构师review

      晚上review是最好的时机,一般没有人打扰,没有会议,我一般选择这个时候

 

3.开发人员两两互review

      开发人员两人一组,一天一次,review当天的代码。但过于频繁,久而久之就成了过场,然并卵。。。

 

4.开发人员在会议室review,个人更倾向于这种

      代码review最好采用小会议室,开发人员一起review,时长一小时最好,不宜过长,在开发阶段一周一次review。讲解人(开发人员)选取自己本迭代做的某个功能点,先讲业务,然后讲架构、实现过程、再讲代码,期间有问题时可以随时打断,听众提问,讲解人一一作答。个人更倾向于这种。 酷

  

四。常用的review软件

     在敏捷开发中,每个迭代的工作量大概在两三周左右,代码量不是很多,但是如果要项目负责人或架构师一一QC所有开发人员的代码,也是个不小的任务,所以,往往需要借助第三方工具。

 

1.checkstyle

      这是一个代码风格的检查工具,要求过于苛刻,一般很难让所有开发人员都按这个标准来。

 

2.PDM

      这是一个静态代码扫描工具,直接扫描java源码,可以发现很多重复的代码、未使用的代码、复杂的表达式、潜在的bug。

 

3.findbugs

      直接操作class文件而不是源码,着重于发现代码中的bug,不注重style及format

 

五。注意事项

1.代码review应该在良好的气氛中进行,这不是批判大会,不应有人身攻击,应就码论码。

2.代码review的目的是提前发现问题的好时候

3.代码review可以让知识共享,是互相学习的好机会

4.代码review能防止某个开发人员单点,让更多的了解他的代码,当他请假或离职,不至于手忙脚乱,有效HA

5.代码review一定要有记录,完事后发出会议纪要给所有开发人员,限期整改,项目负责人或架构师在上线前再次review

 

六。后记

从开发人员来看,代码review会逐步让TA改正不好的习惯,提高编码、设计、架构能力,从而走向人生巅峰,迎娶白富美,哈哈。。。

 

从团队来看,能改善工作氛围、提高团队的凝聚力。

 

从项目来看,可以提前发现问题,减少bug,提高稳定性,不再到处救火。

 



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



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