代码评审
定义
代码评审(有时称为同行评审)是一种软件质量保证活动。代码评审需要一个或多人通过查看和阅读部分源代码来检查程序,他们在实施之后或作为实施的中断进行检查,至少其中一人不得是代码的作者。除作者外,进行检查的人员被称为“审稿人”。
实践出处
历史上第一个详细研究和描述的代码评审过程被其发明者迈克尔费根称为“检查”。费根检查是在软件开发过程的各个阶段试图发现文档(例如源代码或正式规范)中缺陷的过程,它以迈克尔费根的名字命名,而迈克尔费根则被誉为正式软件检查的发明者。
为什么
-
更好的代码质量:提高内部代码质量和可维护性(包括可读性、统一性、可理解性等)。
-
尽早发现缺陷:提高外部质量,发现性能问题、安全漏洞以及注入的恶意软件等。这样,开发人员不用在功能发布后发现缺陷、采取补救措施,而是可以在客户看到问题之前立即发现并修复问题。同时,通过单元测试在软件开发生命周期的早期移动评审过程有助于开发人员利用新的知识进行修复。如果等到生命周期结束进行代码评审,开发人员通常很难记住最初编写代码时的思路和解决方案。
-
学习/知识共享:有助于共享关于代码库、解决方案、质量期望等方面的知识。无论是审稿人还是代码作者,当软件开发人员在团队成员进行更改后立即评审代码时,他们可以学习到一些新技术和解决方案。代码评审可以帮助初级开发人员向更资深的团队成员学习。通过在整个组织中传播知识,代码评审确保没有人是“单点故障”,每个人都有能力进行评审、提供反馈。
-
提高协作能力:增加集体代码所有权和团结感。当团队成员一起工作并提出解决方案时,他们会对自己的工作有更多的归属感和更强的归属感。代码作者和审稿人可以一起寻找最有效的解决方案来满足客户的需求。加强整个软件开发生命周期的协作是很重要的,它能够避免出现信息孤岛,保持团队之间顺畅、无缝衔接的工作流程。为了成功地进行代码评审,开发人员必须建立一种代码评审思维模式,这种思维模式在协作开发中能够打造一个坚实的基础。
-
寻找更好的解决方案:寻找超越现有代码的新的、更好的想法和解决方案。
-
遵守QA指南、ISO/IEC标准:在某些情况下,如空中交通软件、安全关键软件,必须进行代码评审。
何时使用
代码评审应该在自动检查(测试、样式、其他 CI)成功完成之后,但在代码合并到存储库的主线分支之前进行。
如何使用
-
电子邮件线程
一旦一段代码准备好进行评审,就可以通过电子邮件将相应的文件发送给相关同事,让他们在工作流程允许的情况下尽快进行评审。虽然这种方法比传统的评审方法(例如将五个人聚集在房间里召开代码评审会议)更灵活、适应性更强,但这些包含不同建议和意见的电子邮件线程往往会变得复杂起来,最后还需要让最初的编码人员自己整理这些意见和建议。
-
结对编程
作为极限编程(XP)的实践之一,这种编写软件的方法强调开发人员坐在一起处理相同的代码,从而在开发过程中检查彼此的工作。这是资深开发人员指导新人同事的好方法,能够将代码评审直接融入到编程过程中。但由于结对编程的双方太了解自己的工作内容,相比较而言,其他的代码评审方法可能会更加客观。就时间和人员而言,结对编程也比其他方法占用更多的资源。
-
即时代码评审
对于大多数开发人员来说,与XP的结对编程相比,即时代码评审技术是参与同行代码评审的最古老、最简单、最直观的方法之一。一旦你的代码准备就绪,只需找一位有资格的同事坐在你的工位(或去他们的工位)评审你的代码,同时向他们解释你为什么以这种方式编写代码。这种非正式的方法显然是“轻量级的”,但如果在使用这种方法时,没有进行跟踪或记录,那这种方法可能就有点“太轻了”(所以记得带上你的记事本做好记录)。
-
工具辅助
可以说没有比通过基于软件的代码评审工具更简单、更有效的方式来评审代码了,其中一些工具是基于浏览器,或无缝集成到各种标准IDE和SCM开发框架中的。软件工具解决了上述方法的诸多限制,以清晰一致的顺序来跟踪同事的评论和提出的缺陷解决方案(类似于跟踪MSWord中的变化),使评审能够在异步和非本地的情况下进行。当新的评论出现时,工具会向最初的编码人员发出通知,并保持整个流程的高效运行。这种方法无需开会,也不用离开办公桌就可以进行评审。还有一些工具允许评审和修改需求文档,更重要的是,这些工具还可以生成统计数据,提供流程改进和合规报告所需的评审指标。
输出物
代码评审意见
参考资料
-
https://en.wikipedia.org/wiki/Code_review
-
https://about.gitlab.com/topics/version-control/what-is-code-review/
-
https://smartbear.com/learn/code-review/what-is-code-review/
实战案例
以下实战案例来自于麦哲思科技:
某公司是产品开发类项目,产品开发周期比较短,销量比较大,质量要求比较高。2009年11月初开始启动过程改进,导入了每日代码走查这条实践:每天下午5点到6点为固定的代码走查时间,对当天完成的代码进行走查。2人结对,一个作者,一个专家。该公司当时共有200个开发人员,70个系统测试人员。
为了确保这条措施在企业内能够推广下去,公司制定了多方位、多手段、彼此支撑的一系列措施,见下表:
类型 | 措施 |
制度 | 建立每日走查一小时的制度 |
建立每日走查的流程 | |
定义每日走查的检查单 | |
代码走读检查单学习考试 | |
SQA对代码走查的质量进行抽检,识别必须复检的走读 | |
定义代码走查发现的缺陷类型 | |
度量 | 度量代码走查的效率、速率、工作量 |
宣传 | 制定代码走查的宣传标语 |
代码走查的度量数据定期大幅度公布,代码走查的典型人物公开宣传 | |
根据每个人的度量数据识别出代码走查的榜样 | |
人员培养 | 代码走查的典型案例采集 |
典型代码的走查教育 | |
代码走查的内部培训讲师的识别 | |
工具 | 分析Pclint的报警数与系统测试的bugs、客户反馈的Bugs之间的相关性 |
建立Pclint的告警数在转系统测试时的阈值 | |
函数复杂度分析工具的使用SourceMonitor | |
代码行数的统计工具 | |
程序流程自动分析工具的收集与研究 | |
定义Pclint查出的哪些告警必须修改 | |
开发了代码走读的IT系统 |
在推行了1个月后,采集了如表7-5的度量数据。其中代码走查列是200个开发人员每天下午结对代码走查的度量数据,系统测试列是70个系统测试人员在1个月内进行系统测试的度量数据。通过2009年12月份一个月的度量数据的分析,得到这样的结论:代码走查发现缺陷的效率是系统测试的4.25倍。
代码走查 | 系统测试 | 比值 | |
发现的BUGS | 3687 | 4556 | 0.81 |
发现的严重与致命BUGS | 464 | 1511 | 0.31 |
工作量 | 3086.1 | 16062.4 | 0.19 |
检出效率(BUGS/人时) | 1.19 | 0.28 | 4.25 |
严重与致命BUGS的检出效率(BUGS/人时) | 0.15 | 0.09 | 1.67 |
我们非常重视知识产权,我们在非常努力地寻找最初的出处来源并注明出处。但因为互联网信息浩瀚,难免会有疏漏。如果您觉得有侵犯您的权益,请联系我们。