本文翻译自:https://dzone.com/articles/4-types-of-code-reviews-any-professional-developer
转载请注明出处:葡萄城官网,葡萄城为开发者提供专业的开发工具、解决方案和服务,赋能开发者。
没有人能保证他产出的代码一定是完美的。下文阐述了4种主流的代码审查(code review)类型,相信作为专业的开发人员,你应该都了解它们!
每个专业的软件开发者都知道,代码审查是任何正式开发过程中的必要环节。但大多数开发者不知道的是,代码审查分为很多种类型。根据你项目和团队架构的不同,每一种代码审查类型都有它特有的优缺点。
我将在本文列出几种代码的审查的类型,并详细解释它们各自是如何工作的。并且,我也将对你在何时做出哪种选择给出一些建议。
好了,让我们开始吧。
首先,在一个很高的层面,你可以将代码审查归为两大类:正式的代码审查(formal code review),和轻量级的代码审查(light weight code review)。
正式的代码审查
正式的代码审查是基于正式的开发流程。其中最流行的实践是范根检查法(Fagan inspection)。
它为试图寻找代码的缺陷提供了一种非常结构化的流程,并且,它还可以用于发现规范(specifications)中的或者设计中的缺陷。
范根检查法由6个步骤组成:计划(Planning),概述(Overview),准备(Preparation),召开检查会议(Inspection Meeting),重做(Rework),和追查(Follow-up)。基本的思想是:预先制定好每一个步骤所需要达到的输出要求。接下来,当进行到某个过程时,你检查其现在的输出,并与之前制定的理想输出要求做比较。然后,你由此来决定,是否进入下一个步骤,或者仍需在当前步骤继续工作。
这种结构化的流程用的并不多。事实上,在我的职业生涯中,我从没遇到过哪一个团队使用这种方法,而且我也不认为我能在将来看到这种情况。
我认为其原因是,这种流程带来很大的开销,并没有多少团队用到它。
然而,如果你开发的软件生死攸关,会因为有缺陷而让人丧命,那么以这种结构化的方式去查找软件缺陷就显得很合理了。
例如,你是为核电站开发软件。你可能需要一个非常正式的流程去保证最终交出去的代码是没有问题的。
但像我所说,我们大部分开发者所做的软件都不是危及生命的,因此我们使用一种更加轻量的代码审查方法作为正式流程的替代。
所以,让我们来看看这种轻量级的方法。
轻量级的代码审查
如今,轻量级的代码审查在开发团队中很常用。
你可以将轻量级的代码审查细分为不同的子类:
- 瞬时的代码审查,也称为结对编程(pair programming);
- 同步的代码审查,也称为即时(over-the-shoulder)代码审查;
- 异步的代码审查,也称为有工具支持的(tool-assisted)代码审查;
- 偶尔的代码审查,也称为基于会议的(meeting-based)的代码审查。
类型1:瞬时的代码审查
第一种类型是瞬时代码审查,它发生在结对编程的情景中。当一个开发者在敲键盘写代码的同时,另一个开发者盯着代码,注意着代码中潜在的问题,并在此过程中给出提升代码质量的建议。
复杂的业务问题
当你需要解决一个复杂问题时,这种代码审查的方法很适用。在仔细寻找解决方案的过程中,把两个人的脑力聚集起来,会增加成功的几率。让两个头脑思考同一个问题,并相互讨论可行的方案,这样你会更可能覆盖到问题的一些边界情况。
在遇到需要很多复杂业务逻辑的任务时,我喜欢使用结对编程。这样,有助于两个人彻底理清流程中的所有不同的可能性,保证所有情况都在代码中得到了适当的处理。
与复杂的业务逻辑不同,有时,你也会需要去解决一个复杂的技术问题。例如,你在使用一个新的框架,或者在探索之前你没用过的一些新技术。在那种情况下,最好还是单独行动,因为你可以根据自己的情况作出快速调整。为了弄清新技术是如何工作的,你需要上网搜索大量资料,或者阅读文档。
这时,结对编程的帮助就不大了,因为你们会成为各自获取这些知识的阻碍。
然而,当你被问题卡住之后,与你的同事交流一下解决方案,往往会帮你获得看问题的不同视角。
相同的专业水平
考虑进行结对编程的另一个重要方面,是一起工作时,两个开发者的专业水平。两个开发者最好是处于同一水平,因为这样他们才能以相同的速度一起工作。
让一个初级开发者和一个高级开发者进行结对编程,效果并不好。在初级开发者负责写代码的时候,坐在旁边的高级程序员可能会因为他写得太慢了而感到烦恼。如此设定,这个高级程序员的能力就被限制住了,从而浪费了时间。
而当键盘在高级程序员手上时,他又敲得太快,初级程序员跟不上高级程序员的思路。几分钟后,初级程序员就迷失在代码上下文里了。
只有当高级程序员慢下来,向初级程序员解释清楚他的做法,这种设定才合理。然而,这就不是我们所说的结对编程了,而是一种学习的环节,其中高级程序员在教初级程序员如何解决特定问题。
但是,如果两个开发者都在同一水平,在这种设定下,他们所能取得的进展是令人惊讶的。其中有一个很大的好处是,两个开发者能相互激励,当其中一位失去注意力时,另一位开发者能把他拉回正轨。
总结一下:结对编程适用于两个有相似经验水平的开发者处理复杂的业务问题的情况。
类型2:同步的代码审查
第二种类型是同步的代码审查。这种是,一个开发者独自编写代码,当她写完代码后,立即找代码审查者进行审查。
审查者来到开发者的桌前,看着同一块屏幕,一起审查、讨论和改进代码。
审查者不清楚代码的目标
当审查者不清楚这个任务的目标时,这种代码审查类型会很有效果。它会在这种情况下发生:团队里没有优化会议(refinement sessions),或者sprint计划会议(sprint planning sessions),来预先讨论每一项任务。
此做法通常会导致一个结果:只有特定的开发人员才知道某项任务的需求。
这样的情况下,在代码审查之前,向审查者介绍一下任务的目标是很有帮助的。
期待大量的代码改进
如果代码编写者缺乏经验,写出的代码需要很大的改进,那么同步代码审查也会很有效。
如果一个经验丰富的高级开发者将要对一个很初级的程序员写出的一段代码进行审查,那么,当初级程序员写完代码后就和高级开发者一起改进这段代码,效率是远远高于初级程序员自己一个人看的。
强行切换思路的缺点
但是同步审查有一大缺点,就是它强行切换了审查者的思路。它不仅让审查者感到沮丧,也拖慢了整个团队的效率。
类型3:异步代码审查
然后我们有了第三种类型,异步代码审查。这一类型的审查不是在同一时间、同一块屏幕上完成的,而是异步的。开发者在写完代码后,让这些代码对审查者可见,然后开始她的下一个任务。
当审查者有时间了,他会在自己的桌子上按自己的时间表进行代码审查。他而不需要当面和开发者沟通,而是用工具写一些评论。在完成审查后,那些工具会把评论和需要的改动通知给开发者。开发者就会根据评论改进代码,同样的,是以自己的时间表来做这些事情。
这个循环,会以代码改动再次被提交到审查者这里而又重新开始。开发者修改代码,直到没有评论说需要改进。最后,改动得到同意,并提交到主分支(master branch)。
你可以看到,同步的代码审查和异步的代码审查相比有很大的不同。
没有直接的依赖
异步代码审查的一大好处, 就是它是异步发生的。开发者不需要直接依赖于审查者,并且他们都可以按自己的时间表去做各自的工作。
多次审查循环的缺点
这里的缺点就是,你可能会有许多次循环的审查,它们可能会持续好几天,直到最终被接受。
当开发者完成代码后,通常需要几个小时,审查者才开始做代码审查。很多时候,审查者给出的建议只有在第二天才能被开发者修复。
这样,第一次审查周期就至少用掉了一天。如果你又多次这样的循环,审查的时间就延续至一整周了——这还不算写代码和测试的时间。
但这里有一些做法,可以避免这样的长时间间隔导致的失控。例如,在我的团队里,我们规定,每天上午,每个开发者在开始做其他工作之前,都要先处理积压的代码审查任务。同样的,在中午午休结束后也需要这样做。
因为在较长的休息时间后,开发者已经不处在他的代码思路中了。这时进行代码审查,你并没有强制它们进行不自然的思路切换,并且能够让代码在合适的时间得到审查。
对比这种代码审查类型的优缺点,我认为,异步的代码审查应该作为每一个专业开发团队的默认选项。
但在我告诉你为什么我是这么想的之前,让我看看第四种代码审查类型。
类型4:偶尔的代码审查
很久以前,我曾经每个月会和整个团队开一次代码审查会议。我们坐在会议室,一个开发者展示并解释着他最近写的一段困难的代码。
其他开发者尝试寻找着潜在的缺陷,发表评论,给出如何改进代码的建议。
我不认为任何团队和长期地使用偶尔代码审查的方式。我只想到这个类型适用于的一种情况:当整个团队都没有代码审查的经验时,让把每个人聚起来,一起做代码审查,这样弄几次之后,可能会帮助每个人理解代码审查的目标和意义。
然而,从长远来看,这第四种类型并不是一个合适的技术,因为让全组成员审查一段代码是很低效率的做法。
我应该选择哪种代码审查类型呢?
好了,现在你可能会想,该选哪种类型。
我们讨论了正式的类型,它显然不太流行,并且较难用于实践。
然后,我们讨论了轻量级的代码审查这一大类,然后是其中著名的4个子类型。
类型1,瞬时的代码审查,用于结对编程。当两个开发者有相似的技术组合,并且处理一些复杂的业务问题时,这种方式工作得很好。
类型2,同步的代码审查,用于审查者不清楚任务的目标时,需要开发者向其进行解释的这种情况。当开发者经验不足,写出的代码需要大量改进时,这种代码审查模式也工作得很好。
但是它的缺点是需要强行切换思路,会让审查者沮丧,以及拖慢团队开发速度。
类型3,异步的代码审查,避免了强行切换思路带来的问题,对大多数用例都工作得很好。
类型4,偶尔的代码审查,对于专业团队来说不是一个长期的选择。可以只在团队刚刚开始代码审查时被使用。
使用异步代码审查作为默认选择
我认为,专业的团队应该把异步的代码审查作为默认的选择。因为它避免了同步代码审查的缺陷。
当审查者不能理解开发者做出一项代码修改的原因时,可以使用同步的代码审查。但在那种情况下,审查者将会去询问开发者,以获得额外的信息和说明。如果你在一个团队中工作,这样的情况应该很少发生。
如果你不在一个真正的团队中,而是和一群人一起工作,那么同步的代码审查就有意义了。如果审查者对你过去这几天的工作内容毫不知情,那么在开始一起做代码审查之前,向审查者给出一个合适的说明是很合理的。
如果你有两个开发者,他们具备相似的技能组合,并且在攻克一个复杂的业务问题,那么也有理由切换到结对编程的模式。但是,一个团队往往由许多经验水平不同的成员组成,并且不会一直都在处理复杂的业务问题。大多数时间,你手上是复杂度在平均水平的常规任务。
因此,专业团队的最佳选择是:使用异步的代码审查作为默认选择,然后当需要时切换到同步的代码审查或者结对编程。
好了,这就是今天的内容。
你的团队使用什么代码审查的类型呢?你知道其他的、我这里漏掉的代码审查类型吗?请在评论里让我知道吧。
下次再聊。保重。
相关推荐
**Source Insight CodeReview宏**是专门针对Source Insight这款强大的源代码查看和编辑工具设计的一套扩展功能,主要用于代码评审和统计。Source Insight以其强大的代码导航、语法高亮和实时分析能力,深受程序员...
Code Review是软件开发过程中的一个重要环节,它有助于提高代码质量,发现潜在的错误,以及确保团队成员间的代码风格一致。本文将详细介绍两款Eclipse插件——Jupiter和Reviewclipse,它们是进行Code Review的有力...
**正文** 标题提到的"IDEA代码检视插件Code Review Helper"是针对IntelliJ IDEA集成开发环境的一款强大工具,旨在提升代码审查的效率和...对于任何重视代码质量和团队协作的开发团队来说,这都是一个值得拥有的工具。
静态测试方法之代码审查(CodeReview)的清单。代码审查可以帮助提高代码质量,避免由于代码习惯而造成的bug。下面列出的这些要点因该可以作为大部分代码审查的指导,如果是Java应用的话,这些建议应该被视作最佳实践...
Employing lightweight, tool-based code review of code changes (aka modern code review) has become the norm for a wide variety of open-source and industrial systems. In this paper, we make an ...
CodeReview工具的作用:1.减少评审人的缺陷记录和汇总时间,方便责任人查找问题出处;2.检视完成后生成检查报告,代码作者点击按钮可以直接找到错误处;3.任务责任人修改完成后,直接修改问题状态,组织者按快捷键...
Code Review的作用和意义已在很多技术团队内达成共识,可是很多时候并未被有效执行,甚至被认为是一项费时费力的工作。借助一些工具可以更容易,更有效率地来进行Code Review,本文介绍的Jupiter即是其中之一。 ...
包括像Google、微软这些公司,CodeReview都是基本要求,代 我一直认为CodeReview(代码审查)是软件开发中的最佳实践之一,可以有效提高整体代码质量,及时发现代码中可能存在的问题。包括像Google、微软这些公司,...
在Redmine中,Code Review插件是一个重要的扩展,它致力于帮助开发团队进行代码审查,提升代码质量和团队协作效率。本文将详细介绍如何使用Redmine的Code Review插件。 首先,安装Code Review插件是必要的步骤。...
敏捷是当前流行的开发技术,但同样需要进行code review。该如何进行呢?
CodeReview的基本手段还是需要技术经理通过人工检查项目成员的代码,来将各种问题扼杀在开发阶段,但是不同经验及技术水平的经理在review同一段代码所发现的问题可能相差比较大,不同的Team可能因此产生的效果也不同...
软件介绍: 一、软件特色 功能丰富:实现文件内容、度量、命名、注释、类图、Halstead等审查。 简单易用:无需安装,直接使用,直接删除;... 直观可视:分析结果与源代码在同一界面显示对照,...http://www.codereview.com.cn
在软件开发过程中,CodeReview(代码审查)是一项至关重要的活动。它不仅有助于提高代码质量,还能促进团队成员之间的知识共享和技术交流。本文将深入探讨CodeReview中经常遇到的一些代码问题,并提出相应的改进措施...
代码审核,是对应用程序源代码进行系统性检查的工作。它的目的是为了找到并且修复应 用程序在开发阶段存在的一些漏洞或者程序逻辑错误,避免程序漏洞被非法利用给企业带来不必 要的风险。
代码审查(Code Review)是软件开发过程中的一个重要环节,它是一种质量保证活动,旨在通过同行对源代码的系统性检查来发现并修复错误,提高软件的可靠性和可维护性。这个过程通常在代码合并到主分支之前进行,有助...
2 方便开发团队进行Code review。 3 方便教师审查学生代码。 不能做的事(其实本意就是不允许做的): 1 下载文件。 2 查看二进制文件(或许下个版本可以^^)。 特点: 1 全配置文件方便扩展和修改。 ...
Jupiter是一款开源的Eclipse插件,以XML形式存储review数据,通过SVN/CVS将review结果在团队内共享。一个很方便的功能是其建立了review问题跟具体源代码的对应关系(通过点击review问题列表中的问题可以跳转到对应的...
根据给定的文件信息,我们可以提炼出关于代码审查(Code Review)及其在谷歌开发流程中的应用的关键知识点。 ### 什么是代码审查? 代码审查是一种软件工程实践,其中一名开发者编写代码后,由另一名开发者进行...
zyh-code-review.rarzyh-code-review.rarzyh-code-review.rarzyh-code-review.rar