• 常见的代码审查方法有哪些?
  • 发布于 1周前
  • 26 热度
    1 评论

代码审查,或称对等代码审查,是有意识地、有系统地与其他程序员一起检查彼此的代码是否有错误的行为,并且已经被反复证明可以像其他实践一样加速和简化软件开发过程。有对等代码审查工具和软件,但是概念本身很重要。软件是人编写的。因此,软件经常充满错误。犯错的当然是人,所以这有一个明显的关联。但不太明显的是,为什么软件开发人员经常依赖人工或自动测试来审查他们的代码,而忽略了人的另一个伟大天赋:看到并自我改正错误的能力。


不管你是软件开发经理还是一线的程序员,你都可能忽略代码审查或代码检查的巨大好处,这将会让你自己承担风险。如果做得正确,对等审查可以节省时间,显著简化开发过程,并大幅减少质量保证团队之后的工作量。审查能够找出很多有可能会通过测试(漏掉了)、进入生产环境而最终进入用户的笔记本电脑中的未被发现的错误(因为这些错误,烦恼的顾客可能会在亚马逊或应用商店对你的产品发表严厉的评论,你的销售也会因此受到影响),进而实际上能够为你省钱。阅读本文来探索代码审查对每个开发团队都至关重要的其他原因。


此外,不止节省时间和金钱这些软件开发业务中至关重要的问题,代码审查也带来了一些额外的、更加以人为中心的投资回报。鼓励程序员相互谈论他们的代码的工作环境往往会促进更多的交流和友谊,传播任何代码的“所有权”感,并为初级开发人员提供宝贵的经验——高级同事通过实际例子所展示的,编写干净代码的更好方法,用有用的快捷方式解决常见问题,以及直观地识别任何潜在的故障点,如内存泄漏、缓冲区溢出或可扩展性问题。


总而言之,这些因素应该会鼓励任何开发团队去建立一个智能的战略性代码审查流程——如果他们还没有这样做的话(特别是考虑到统计数据)。毕竟,一个严肃的图书出版商会敢于在没有编辑团队的情况下印刷成千上万份作者的作品吗?对于软件的作者和出版商来说,同样的逻辑也适用。但是现在,随着生产周期越来越短,从哪里开始呢?


理解代码审查
对任何想到代码审查的人,回顾他们几年前的做法,在快节奏的敏捷工作场所引入这样一个系统的前景似乎是一种残忍的、不同寻常的惩罚。早在1976年,当IBM的Michael Fagan发表了他的开创性论文《设计和代码检查以减少程序开发中的错误》时,正式的、系统的代码审查的想法就迅速流行起来了(早期版本的对等审查往往不太结构化),通常包括一群人围坐在闷热的房间里的一张桌子旁,一起浏览电脑代码的点阵打印稿,手中拿着红色的笔,直到他们头晕眼花。但是仅仅因为某件事很痛苦,并不意味着它不值得付出努力。正如Capers Jones和Olivier Bonsignour在2011年一篇名为《你检查了吗?》的博文中说到 :
Tom Gilb是处理软件检查的著名作者之一,他和他的同事们最近的工作继续证实了他们早期的发现,即人类检查代码是发现和消除源自需求、设计和其他非编码交付的复杂问题的最有效方法。事实上,为了识别源代码中更深层次的问题,正式的代码检查在缺陷去除效率上超过了测试。

尽管如此,随着计算机和软件开发世界中的其他事物的发展,代码审查已经发生了巨大的变化,现在有许多变种可供选择。如今,尽管长期的正式代码审查过程一如既往地有效,但通常并不需要,除非是在软件工程中,要求错误率几乎为零,例如在航空电子或其他受监管的行业中,人的安全优先于一切。但对于大多数其他情况,随着时间的推移,一系列“轻量级”对等审查的过程已经有机地发展起来,其中许多过程与同样轻量级的敏捷工作流和迭代生产周期完全兼容。有几种常见的敏捷友好的代码审查方法,每种方法都有其局限性。


常见代码审查方法


1.电子邮件审查

一旦给定的代码准备好进行审查,文件就会通过电子邮件发送给相应的同事,让他们在工作流程允许的情况下尽快进行审查。虽然这种方法肯定比更传统的技术更灵活和适应性更强,比如让五个人聚在一个房间里参加一次代码检查会议,但是包含建议和不同意见的电子邮件往往会很快使事情变得复杂,只留下最初的编写人员独自理清头绪。


2.配对编程
作为极限编程( XP )的标志之一,这种编写软件的方法让开发人员并肩工作(至少是象征性的),一起处理相同的代码,从而在他们前进的过程中检查彼此的工作。对于高级开发人员来说,这是一个指导初级同事的好方法,而且似乎将代码审查直接纳入了编程过程。然而,由于作者或配对者倾向于过于接近他们自己的语法,因此其他的代码审查方法可能比本方法有更多的客观性。配对编程在时间和人员方面也比其他方法使用更多的资源。


3.即时审查

对于大多数开发人员来说,这种方法比XP的配对编程更舒适,旧的跨平台技术是参与对等代码审查的最简单和最直观的方式。一旦你的代码准备好了,就找一个合格的同事去你的工作站(或者去他们的工作站)查看你的代码,就像你向他们解释你为什么这么写一样。这种非正式的方法当然是“轻量级的”,但是如果缺乏跟踪或文档记录的方法,它可能会有点太轻。(提示:带上记事本。)


4.工具辅助审查

我们把我们个人最喜欢的东西保存到最后,因为可以说没有比基于软件的代码审查工具更简单、更有效的方式来审查代码了,其中一些工具是基于浏览器的,或者无缝地集成在各种标准IDE和SCM开发框架中。软件工具解决了上述方法的许多局限性,以清晰一致的顺序跟踪同事的评论和缺陷的建议解决方案(类似于跟踪MS Word中的变化),使得评论能够异步和非本地进行,当新的评论出现时,向原始编码人员发出通知,并保持整个过程高效运行,无需召开会议,也无需任何人离开办公桌。一些工具还允许审查和修订需求文档,重要的是,还可以生成关键使用统计数据,提供流程改进和合规性报告所需的审计试验和审查指标。


跟踪你的进展
不管你喜欢哪种代码审查方法,不言而喻,度量标准在代码评审领域很重要,尤其是有这么多开发团队还在等着确信它作为常规实践的最终效果。然而,没有比跟踪实际指标更好的方法来证明和智能地利用所需的时间和脑力——这就是为什么一些现有的研究如此有启发性的原因,例如2005 - 2006年SmartBear软件对Cisco的对等代码审查过程进行的分析,该分析调查了50名开发人员撰写的320万行代码的2500次审查(完整的研究在SmartBear的深度电子书《对等代码审查的最佳保密秘密》中介绍)。
结果呢?不仅Cisco的代码审查过程检测到的错误或缺陷远远超过了常规测试本身所能发现的,而且这些度量标准(从如此大的样本集中得出)让研究人员能够收集到以下关于代码审查的重要见解:
1.审查中的代码行( LOC )应该少于200行,不超过400行,因为任何更多的代码会超出审查者的能力上限,他们从而不能发现缺陷。
2.低于300LOC /小时的检查率有利于最佳的缺陷检测,低于500LOC /小时的检查率仍然很好,但是如果LOC的检查速度超过这一速度,预计会错过很大比例的缺陷。
3.用注释和解释来辅助审查的作者比没有注释和解释的作者缺陷要少得多。原因可能是作者被迫自我审查自身的代码。
4.总审查时间应少于60分钟,不超过90分钟。超过90分钟的审查,缺陷检测率会直线下降。
5.预计缺陷率约为每小时15个。这个比率只能在审查中低于175 LOC时更高。
6.在同一电子书中记录的另一个案例研究中,SmartBear团队报告说,一名客户希望降低每年拨打客户支持电话的高昂成本,他们确定每次电话费用为33美元。从每年50,000次呼叫开始,在实施系统的代码审查程序以消除软件缺陷(因为计算机故障会向客户支持部门发起随机呼叫)和提高可用性(减少困惑的客户致电技术支持)后的几年内,支持呼叫的频率下降到每年仅20,000次(尽管产品销售增长了200 % ),相当于节省了260万美元。
很明显,正确的对等代码审查不仅简化了软件,还简化了底线。你可以在我们的代码审查学习中心看到其他代码审查最佳实践。


对等代码审查的未来

当然,尽管我们在本文中强调了这一点,但是代码审查只是任何软件生产团队质量保证计划的一个组成部分,许多不同的测试和静态分析构成了QA核对表。但是这是一个重要的组成部分,经常在bug产生后和它们有时间成长为更大的问题之前就消灭它们,并且识别“隐藏”的bug,这些bug现在可能没有问题,但是可能会阻碍产品未来的发展。


单元测试总是有助于确定给定功能是否如预期的那样“工作”,但是代码审查可以阐明更适合人类感知的更微妙的问题——例如可伸缩性、错误处理和基本易读性(包括开发人员注释和需求文档的书面清晰性)。正如测试自动化变得越来越复杂并且成为测试团队选择的主要武器一样,工具辅助的对等代码审查也有可能最终取代其他“轻量级”形式,成为最合适和最包容的方法。


在一个软件生产进度不断加快的世界里,持续部署正在成为常态,客户反馈是一个无止境的循环,越来越依赖正确的数字工具来获得最大的效率是有道理的。github效应对代码审查的影响可以从开发团队实际进行的越来越多的审查中感受到。


但是即使从现在起10到20年后,除非新软件开始自行编写,我们可以放心,对等代码审查的主要组成部分——即人类——仍将占据中心位置。事实上,只要有人类进行代码审查,这意味着即使没有软件审查工具,代码仍将继续改进,这完全要归功于人类的心理。


如同Jason Cohen,SmartBear软件的创始人在一个他称之为“自我效应”的现象中指出,知道别人会批评你的工作,会自动让你成为一个更好、更认真的开发者。没有人想在同事面前看起来很糟糕,这一事实本身就可以成为编写更好代码、给予更多关注、让更少的错误从我们易出错的人性的许多裂缝中穿过并进入白昼的强大动力。

用户评论