优大网

标签存档: 代码审查

代码审查,也要天时地利人和

摘要:代码评审是指在软件开发过程中,通过对源代码进行系统性检查的过程。通常目的是查找系统缺陷,保证软件总体质量和提高开发者自身水平。这可不是一件简简单单的事。

当代码审查被广泛采用的时候,有很多种方法可以完成代码审查,团队争相使用最好的方法来完成代码审查已经是很常见的了。

斗胆的说一句:干这行的,你还是需要一点灵活性的。至于怎样执行代码审查程序取决以下几点:

人员

你的员工当中有多少开发人员,又有多少专业知识和人际水平都很丰富的审查人员?有的团队里只有一个高级开发人员,他们既是事必亲躬的代码员,又是代码审查员,可他们的所得和付出并不成正比。在一个小的团队里,资历高低一直是个问题,不管你试图完成什么任务。

地理位置

你的团队在哪?分散在各个区域?还是集中在一个大办公室里?审查代码需要集中注意力和及时反馈,当开发人员坐在一起的时候这两点就变得容易多了。如果你的团队不是同地协作,像“Over-the-shoulder”这样的代码审查过程就很难实现。

行业

所在的这个行业有什么规则和制度?在一个纪律严明的行业,你就必须遵守审计和报告的规则,这就意味着有一定的方法可以追踪到你的代码审查的频率和质量。如果你在安全性第一的行业,在代码审查的时候你同样需要关注并避免安全漏洞。

复杂性

你的代码有多复杂?一个审查员够了吗?还是需要多个具备不同专业知识的审查员?比方说,游戏开发可能涉及到许多复杂的逻辑来处理角色转换和场景跟踪,同时还要将特效动画和内存管理技术进行合并。因此,具有多个“Sets of eyes”的代码可能是审查像游戏开发这样复杂代码最有效的方法。

许多情况下,对于不同的项目会有不同的需求——你可能有多个团队正在搭建用户配置和需求都不一样的应用程序。一个你信得过的代码审查工具能够帮你完成高质量的代码审查流程,不管你使用的是什么方法。下面给出一些小建议,审查流程结合审查工具,这也许能解决你平时遇到的一些问题。

1. 加强交流

任何类型的审查过程,不管是代码审查,文献审查,或是性能审查,最好能够面对面的完成。当使用工具完成代码审查之后,开发人员在规定时间内提供语言反馈,如果不在同一地点,可以通过电话或视频对反馈的信息进行交流,因此,你也可以把代码审查过程看作是一次合作与指导的机会。

2. 发挥特长

如果正在审查的代码和其他区域的代码有接触点,或对安全,性能,延伸性等有影响,那就必须让更多的人检查代码以确保所有的分枝都已被考虑到位。在这种情况下,最好建立一个包含所有专业知识的人员库。这个工具可以帮助你甄别这些有用的人,并分配到需要的代码团队。你也可以利用这个工具收集所有人员的评论并分享给整个审查团队,这样大家可以相互学习。

3. 共享代码审查评论

使用工具的好处之一就是集中人员来审查相同的代码,将一组人集中到一起做小组评审,让每个人站在自己的角度思考代码里潜在的“问题”。每一个人都要对代码进行评论,并且允许团队成员看到相互之间的评论。能同时看到代码和别人的评论对整个团队来说是有很多好处的:

 

  • 没有重复的评论——第一个人说过的,第二个人就不能重复说。
  • 团队学习——能够看到其他人的评论,审查员可以相互学习。
  • 重复审查——有些时候一个审查员可以抓住另一个审查员的错误,这样就可以阻止错误被引入代码。

 

4. 审查指标

在代码审查过程中有一件事是肯定的,那就是使用工具指标。利用指标作为改进代码库的方法,这在代码审查过程具有很强的附加功能。工具可以告诉你哪些是最常见的错误,它们被引用在哪里,又在哪些地方重复过。同时可以根据在循环审查阶段,建立在缺陷记录基础上的质量问题,来判断哪些代码看上去易受攻击。在检查的时候就能阻止bugs,这明显是确保代码质量的最经济最高效的方法。metrics的使用还可以帮助开发人员找到哪些方面需要加强训练,以便以后开发出更好的代码。

5. 挖掘未来的代码审查员

你必须提升自己的的高度。因为要想识别出团队里的人哪些是可以进入审查员角色,就要花很大的精力和时间。理想情况下,你团队里的所有开发人员都能执行同行审查,这是合作程度和效率最高的方法,为了能够准时交付优质代码。但这需要花大量的时间和精力来打造这样一个高水平的团队。

代码审查很重要,审查过程中,审查人员和开发人员不是对立的关系,而是互助、沟通、协作和学习的过程。团队形成互助、互学的气氛,既能互相增长团队的知识和经验,还能把产品做得更好。Code Review的核心是:互助,沟通,协作,学习的过程,这是一个美妙而享受的过程,是跨越需求分析、架构设计、编码等各阶段的过程。(编译/薛梁 责编/夏梦竹)

原文:smartbear

http://www.csdn.net/article/2013-06-20/2815921-Making-Code-Review-Work

代码审查——提高代码质量的终极武器

摘要:SmartBear公司发起一项调查研究2013年代码审查的使用情况并从超过650名专业开发人士那收集了“实践经验”,结果非常有趣。90%的受访者表示代码审查提高软件质量;74%表示代码审查还有助于跨团队之间知识共享。

如果糟糕的软件是我们的克星,那么优秀的代码就是解药。

软件无法工作是件非常恼人的事!而这种情况往往是由于糟糕的代码所致。在一个项目中,如果开发者孤军奋战,这种情况出现的几率就会增大。

幸运的是,团队中的一些成员愿意贡献自己的空闲时间来改善软件质量。通常,这些人就是我们常说的QA测试者——他们坚持不懈地寻找bug。这里有一个最佳实践方式能够更有效地识别软件代码中的缺陷——同行代码审查(peer code review)。

研究表明,同行代码审查是寻找代码缺陷最高效的方法。有分析称超过12000软件代码使用同行代码审查可以完成60%的效率,而使用单元测试只有25%。每隔一小时使用同行代码审查,可以为开发团队的QA测试节省20个小时,这个听起来不错吧。

近日,SmartBear公司发起一项调查研究2013年代码审查的使用情况。超过650名专业开发人士回答了如何使用代码审查以及对性能影响的相关问题并从中收集了“实践经验”,结果非常有趣。

在此次调查中超过70%的受访者参与了不同程度的协同审查,结果发现,那些做代码审查的比不做代码审查的软件整体质量满意度高达2倍。

我们从中抽取了一个问题,一起来看下代码审查能带来哪些好处。

Q:你认为代码审查最大的好处是什么?

如图所示,显而易见,代码审查最大好处莫过于提高软件质量;74%的受访者表示,代码审查还有助于跨团队之间知识共享;有60%的受访者还发现,代码审查有助于团队之间相互指导及提升协作。

由此可以看出:

 

  1. 代码审查是提高开发团队技能以及保持团队迭代更新最有效的最佳实践方法。
  2. 代码审查工具辅助文档过程本身允许大家互相学习和更正评论。
  3. 假如做代码审查的开发者碰巧没坐在你边上或者开发团队遍布全球或者某个疯狂的同事从凌晨1点工作到5点,那么代码审查工具可追踪任何一条评论以方便你在空闲的时候查看。

 

代码审查不仅能帮助你确保评审、改进代码,还能为开发人员节省大量的时间,帮助你拯救因糟糕软件无法正常运行而带来的压力。

英文出自:Smartbear

http://www.csdn.net/article/2013-06-03/2815518-code-review

高效代码审查的十个经验

http://kb.cnblogs.com/page/163000/

  代码审查(Code Review)是软件开发中常用的手段,和QA测试相比,它更容易发现和架构以及时序相关等较难发现的问题,还可以帮助团队成员提高编程技能,统一编程风格等。

  1. 代码审查要求团队有良好的文化

团队需要认识到代码审查是为了提高整个团队的能力,而不是针对个体设置的检查“关卡”。

“A的代码有个bug被B发现,所以A能力不行,B能力更好”,这一类的陷阱很容易被扩散从而影响团队内部的协作,因此需要避免。

另外,代码审查本身可以提高开发者的能力,让其从自身犯过的错误中学习,从他人的思路中学习。如果开发者对这个流程有抵触或者反感,这个目的就达不到。

2. 谨慎的使用审查中问题的发现率作为考评标准

  在代码审查中如果发现问题,对于问题的发现者来说这是好事,应该予以鼓励。但对于被发现者,我们不主张使用这个方式予以惩罚。软件开发中bug在所难免,过度苛求本身有悖常理。更糟的是,如果造成参与者怕承担责任,不愿意在审查中指出问题,代码审查就没有任何的价值和意义。

3. 控制每次审查的代码数量

根据smartbear在思科所作的调查,每次审查200行-400行的代码效果最好。每次试图审查的代码过多,发现问题的能力就会下降,具体的比例关系如下图所示:

  我们在实践中发现,随着开发平台和开发语言的不同,最优的代码审查量有所不同。但是限制每次审查的数量确实非常必要,因为这个过程是高强度的脑力密集型活动。时间一长,代码在审查者眼里只是字母,无任何逻辑联系,自然不会有太多的产出。

4. 带着问题去进行审查

我们在每次代码审查中,要求审查者利用自身的经验先思考可能会碰到的问题,然后通过审查工作验证这些问题是否已经解决。一个窍门是,从用户可见的功能出发,假设一个比较复杂的使用场景,在代码阅读中验证这个使用场景是否能够正确工作。

使用这个技巧,可以让审查者有代入感,真正的沉浸入代码中,提高效率。大家都知道看武侠小说不容易瞌睡,而看专业书容易瞌睡,原因就是武侠小说更容易产生代入感。

有的研究建议每次树立目标,控制单位时间内审核的代码数量。这个方法在我们的实践中显得很机械和流程化,不如上面的方法效果好。

5. 所有的问题和修改,必须由原作者进行确认

如果在审查中发现问题,务必由原作者进行确认。

这样做有两个目的:

(1) 确认问题确实存在,保证问题被解决。

(2) 让原作者了解问题和不足,帮助其成长。

有些时候为了追求效率,有经验的审查者更倾向于直接修改代码乃至重构所有代码,但这样不利于提高团队效率,并且会增加因为重构引入新bug的几率,通常情况下我们不予鼓励。

6. 利用代码审查激活个体“能动性”

即使项目进度比较紧张,无法完全的进行代码审查,至少也要进行部分代码的审查,此时随即抽取一些关键部分是个不错的办法。

背后的逻辑是,软件开发是非常有创造性的工作,开发者都有强烈的自我驱动性和自我实现的要求。让开发者知道他写的任何代码都可能被其他人阅读和审察,可以促使开发者集中注意力,尤其是避免将质量糟糕,乃至有低级错误的代码提交给同伴审查。开源软件也很好的利用了这种心态来提高代码质量。

7. 在非正式,轻松的环境下进行代码审查

如前所述,代码审查是一个脑力密集型的工作。参与者需要在比较轻松的环境下进行该工作。因此,我们认为像某些实践中建议的那样,以会议的形式进行代码审查效果并不好,不仅因为长时间的会议容易让效率低下,更因为会议上可能出现的争议和思考不利于进行如此复杂的工作。

8. 提交代码前自我审查,添加对代码的说明

所有团队成员在提交代码给其他成员审查前,必须先进行一次审查。这次自我修正形式的审查除了检查代码的正确性以外,还可以完成如下的工作:

(1) 对代码添加注释,说明本次修改背后的原因,方便其他人进行审查。

(2) 修正编码风格,尤其是一些关键数据结构和方法的命名,提高代码的可读性。

(3) 从全局审视设计,是否完整的考虑了所有情景。在实现之前做的设计如果存在考虑不周的情况,这个阶段可以很好的进行补救。

我们在实践中发现,即使只有原作者进行代码审查,仍然可以很好的提高代码质量。

9. 实现中记录笔记可以很好的提高问题发现率

成员在编码的时候应做随手记录,包括在代码中用注释的方式表示,或者记录简单的个人文档,这样做有几个好处:

(1) 避免遗漏。在编码时将考虑到的任何问题都记录下来,在审查阶段再次检查这些问题都确认解决。

(2) 根据研究,每个人都习惯犯一些重复性的错误。这类问题在编码是记录下来,可以在审查的时候用作检查的依据。

(3) 在反复记录笔记并在审查中发现类似的问题后,该类问题出现率会显著下降

10. 使用好的工具进行轻量级的代码审查

“工欲善其事,必先利其器”。我们使用的是bitbucket提供的代码托管服务。

每个团队成员独立开发功能,然后利用Pull Request的形式将代码提交给审查者。复审者可以很方便在网页上阅读代码,添加评论等,然后原作者会自动收到邮件提醒,对审阅的意见进行讨论。

即使团队成员分布在天南海北,利用bitbucket提供的工具也能很好的进行代码审查。

Copyright © 2021 优大网 浙ICP备13002865号-3

SITEMAP回到顶部 ↑