关于代码审查的几点建议

标签: 编程技术 代码审查 | 发表时间:2014-09-04 08:51 | 作者:techug
出处:http://www.vaikan.com

Code Review即代码审查是软件开发中常用的手段,它和QA测试相比,更容易发现架构以及时序相关等较难发现的问题,还可以帮助团队成员统一编程风格,提高编程技能等。代码审查被公认为是一个提高代码质量的有效手段。目前很多开发团队虽然进行了代码审查,但是他们可能没有有效、合理的进行代码审查,以致没有很好达到代码审查的目的。近日,BIDS 贸易科技有限公司的CTO Jim Bird 总结了关于代码审查的一些建议。现对这些建议进行了一个全面的梳理,具体内容如下:

1 、代码审查不要太正式

目前,有很多研究表明正式代码的评审会议会延误开发进度和增加开发成本。尽管可能只需要几周的时间进行代码评审,但是只有4%的缺陷是在会议期间发现的,其余所有的权限是靠代码审查者自己发现和处理的。只有采用简短、轻量的代码审查才是有效的发现问题在代码检查,这样的代码审查更适合迭代、增量开发,为开发者提供更快的反馈。

2 、代码审查人员要尽可能少

并不是代码审查人员越多就能发现越多Bug,只有合理数量的审查人员才能够更加有效的地审查代码。研究表明,平均来说,一个代码审查人员能够发现Bug的一半, 第二审稿人会发现剩余新问题的一半。多个人同2个人发现问题的数量没有太大差异,故两个人进行代码审查是比较合适的。另外,还由于社会惰性的存在,更多代码审查人员意味着多人在寻找同样的问题,使得审查人员积极性、主动性不高,更加不利于代码审查工作的有效进行。

3 、需要有经验的开发者进行代码审查

研究充分表明,代码审查的有效性依赖于审查人的技能和对问题领域以及代码的熟悉程度。如果让新加入团队的成员进行代码审查的话,并不利于他们的成长,且对于代码审查来说也是一种非常糟糕的方式。只有擅长阅读代码、程序调试、非常熟悉语言、框架、对应的问题的人才最适合代码审查,才能够高效发现问题、提供更多有价值的反馈。新的、没有经验的开发者只适合检查代码的变化和使用静态分析工具并和另一位评论人员共同代码审查。

4 、实质重于方式

完全按照编码规格标准进行的代码审查是一个浪费开发人员宝贵时间的方式。代码审查的实质是确认代码能够正确的运行,发现安全漏洞、功能错误、代码错误、设计失误、安全验证和防范、恶意代码等。而不是单单按照编码规范完全保证代码格式一致,而丢失了代码审查的实质。

5 、合理安排 Bug 和可维护性问题代码的审查时间分配

发现代码中的Bug是很难的,在别人的代码找到的Bug更难。研究表明,代码审查人员找到Bug和可维护性、可读性问题的比例是25:75,故消耗在了代码可读性、可维护性等问题上和Bug上的代码审查时间应该合理分配。

6 、尽量使用静态代码分析工具以提高审查效率

工欲善其事,必先利其器。静态代码分析工具可以帮助程序开发人员自动执行静态代码分析,快速定位代码隐藏错误和缺陷;帮助代码设计人员更专注于分析和解决代码设计缺陷;显著减少在代码逐行检查上花费的时间,提高了软件可靠性并节省软件开发和测试成本。

7 二八定律处理高风险代码

审查所有的代码并没有太大的意义,应该把审查的重点放在高风险的代码和容易引起高风险的修改或者重构的代码上。旧而复杂、处理敏感数据、处理重要业务逻辑和流程、大规模重构以及刚加入团队的开发者实现的代码都是审查的重点。

8 、从代码审查中尽量获得最大的收益

虽然代码审查是发现Bug、提高开发人员代码编写质量的重要方式,但是它也增加了代码开发成本。如果没有合理、有效的进行代码审查,将有可能影响项目进度和破坏团队文化。故我们要紧抓代码审查的实质性问题,尽早和经常性的进行非正式的代码审查;选择精而少的人员并运用二八定律审查高风险的代码,同时,还需要合理分配Bug以及可维护性问题的代码审查时间,才可以从代码审查中获得最大的收益。

相关 [代码审查] 推荐:

代码审查过程

- - 博客园_知识库
   英文链接: Code Review Processes.   对我而言,把代码产品化而没有合适的审查流程,就像是一场抽抽乐游戏. 代码当然也有可能会挺好,不过总还是有一定概率某人的哪块积木没抽好,然后一切就轰然崩塌. 无论是采用持续集成服务、结对审查、QA审查,还是所有这些方案的组合,都可以大大降低引入风险的概率.

Google 是如何做代码审查的

- litefy - python.cn(jobs, news)
在上一篇文章中提到过,我已经不在Google工作了. 我还没有想清楚应该去哪里—有两三个非常好的工作机会摆在我面前. 因为在这段做决定时间里,我不再受雇于任何人,我想可以写一些专业性的东西,一些很有趣,但也会在同事和管理工作中导致关系紧张的东西. Google是一个非常优秀的公司. 他们做出了很多令人称赞的东西—既是公司外部,人们可以看到的东西,也是公司内部.

代码审查中应该做的事

- China Moon - Solidot
威客 写道 "Mark Chu-Carroll从Google离职后,虽然已经收到了很多offer,但还没有决定去哪里. 他在其博客中分享了一些关于代码审查的趣事(中文). Google确实是一家很酷的公司. 不论是在公司内部或是外部,Google都做了很多让人赞叹的的事情. 这里我想介绍一些不涉及商业机密,但鲜为外人所知的事情.

敏捷代码审查指南

- - 博客 - 伯乐在线
“通过一次真正彻底地代码审查(code reviews),仔细阅读你的代码,找出问题,这是我知道的最好的方式去检测早期的bug,但是他们很少去这样干过. 某种意义上是因为他们花了大量的时间去写好代码,但是我认为主要是因为绝大部分 程序员害怕其他人审查自己的代码. 作为专业的程序员我们要克服阻力,如果你不愿意别人阅读你的代码,然后只是按照自己的意愿写,如果其他人没法读懂它,又怎能让别人使用呢.

代码审查(Code Review)清单

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

我所钟爱的代码审查

- - 译言-电脑/网络/数码科技
This is pretty standard fare for developers in the "real world", but I have never heard of an academic research group using them, and had never done code reviews myself before joining Google..

代码审查不是用来……

- - 外刊IT评论
提示:如果您在阅读器里点击订阅本站的文章链接时发现有一个中转页,这说明你的订阅地址有误,本站的订阅地址(RSS)是:. http://www.aqee.net/feed/,请及时纠正. 事实上,今天的我们正是从这种一直坚持探索的漫长道路上走出来的. 我们尝试各种技术、方法和工具,直到我们走到今天的成就(但这并不是说我们就此停步).

我们如何进行代码审查

- - CSDN博客研发管理推荐文章
本文来源于我在InfoQ中文站原创的文章,原文地址是:. Jim Bird是一位经验丰富的软件开发经理、项目经理与CTO,专注于软件开发与维护、软件质量与安全等领域中疑难问题的解决. 在过去的15年间,Jim曾管理过团队建设并主导过高性能的财务系统的建设. 他的主要兴趣在于如何提升小团队的效率以构建真正的软件:高质量、安全、可靠、高性能及适应性强.

你们公司做代码审查吗?

- - 外刊IT评论
每当从各种公司听到他们正在尝试自动化部署/测试的事情,我都非常关注,但通常会很吃惊,他们很少会考虑去实行代码审查制度. 看到这种情况,我通常想问: 如果代码没有经过其它人的审查,你如何知道你要测试的是什么. 这答案(如果有的话)通常是捏着手指头说 有几个人在做代码审查或“正在考虑中”. 不论你采用什么形式的测试过程,什么形式的部署过程,没有代码审查——game over.

[原]代码审查审什么

- - 阿朱=行业趋势+开发管理+架构
看着很多人做代码审查重点审格式和命名,制定的代码规范也主要偏重代码格式和命名,我真想骂一句操蛋,这真是浪费时间又解决不了问题. 此篇文章就是骂完操蛋后奋笔快速敲下来的,有不妥之处请大家谅解. 一、目的:为啥要花费时间要搞人工代码审查. 1、有些问题是工具检查不出来的,需要人工审查. 2、有些问题是不希望花大代价来发现、或者上线后才知道.