任何专业开发人员都应该了解的4种代码审查



每个专业的软件开发人员都知道代码评审应该是任何严肃的开发过程的一部分。但是大多数开发人员不知道的是,有许多不同类型的代码评审。根据您的项目和团队结构,每种类型都有特定的优点和缺点。

在这篇文章中,我将列出不同类型的代码评审,并解释每种类型是如何精确工作的。我也会给你一些关于何时使用哪种类型的想法。

好了,我们开始吧。

首先,在很高的层次上,您可以将代码评审分为two different categories —正式代码评审和轻量级代码评审。

正式代码审查

正式的代码评审是基于正式的过程。这里最流行的实现是Fagan inspection

在这里,你有一个非常结构化的过程来试图发现代码中的缺陷,但是它也用于发现规范或设计中的缺陷。

法甘检查包括六个步骤:计划、概述、准备、检查会议、返工和跟进。基本思想是预先定义每一步的输出需求,当运行整个过程时,检查每一步的输出并将其与期望的结果进行比较。然后你决定是继续下一步,还是继续做当前的工作。

这种结构化的方法并不常用。事实上,在我的职业生涯中,我从来没有遇到过使用这样一个过程的团队,我认为我永远也看不到这一点。

我认为这是因为这个过程带来了很大的开销,所以没有很多团队使用它。

然而,如果你不得不开发一个软件,在出现缺陷的情况下可能会导致生命的损失,那么这样一个寻找缺陷的结构化方法是有意义的。

例如,如果您为核电厂开发软件,那么您可能希望有一个非常正式的方法来保证交付的代码中没有错误。

但是正如我所说的,我们大多数开发人员都在开发不威胁生命的软件,因此,我们使用更轻量级的方法来进行代码评审,而不是正式的方法。

让我们来看看轻量级代码评审。

轻量级代码审查

如今,开发团队通常使用轻量级代码评审。

您可以将轻量级代码评审分为以下不同的子类:

  1. 即时代码审查,也称为结对编程;
  2. 同步代码评审,也称为越肩式代码评审;
  3. 异步代码评审,也称为工具辅助代码评审;
  4. 偶尔进行代码审查,也称为基于会议的代码审查。

类型1:即时代码审查

第一种类型是即时代码审查,它发生在成对编程期间。当一个开发人员敲击键盘生成代码时,另一个开发人员同时检查代码,关注潜在的问题,并随时给出代码改进的想法。

复杂的商业问题

当你必须解决一个复杂的问题时,这种类型的代码审查工作得很好。通过集思广益来完成寻找解决方案的过程,你就增加了把事情做好的机会。用两个大脑思考问题并讨论可能的情景,更有可能的是你也涵盖了问题的边缘情况。

我喜欢在处理需要大量复杂业务逻辑的任务时使用结对编程。然后,让两个人思考流程的所有不同可能性,并确保在代码中正确处理所有可能性,这是很有帮助的。

与复杂的业务逻辑相反,有时你也在处理一个有复杂技术问题需要解决的任务,例如,如果你使用一个新的框架或者探索一项你以前从未使用过的技术。在这种情况下,最好自己工作,因为你可以在自己的基础上工作。你必须在网上做大量的搜索或者阅读关于新技术如何工作的文档。

在这种情况下进行结对编程是没有帮助的,因为在获得所需知识的同时,你们会相互阻碍。

然而,如果你陷入困境,那么与同事谈论解决方案通常有助于你从不同的角度看待问题。

同等专业水平

做结对编程时要考虑的另一个重要方面是两个开发人员一起工作的专业水平。两个开发人员最好在同一水平上,因为这样他们就能以相同的速度一起工作。

大三和大四的结对编程效果不太好。如果小的有方向盘,那么他旁边的大的就会感到无聊,因为他觉得一切都太慢了。在这种情况下,长者的潜力受到限制,因此是在浪费时间。

如果高年级学生手里拿着键盘,那么对低年级学生来说一切都太快了。低年级学生无法理解高年级学生的基础,几分钟后,他就失去了背景。

只有当高年级学生放慢速度,并确保他以较慢的速度向低年级学生解释他将要做什么时,这种设置才有意义。然而,我们不再谈论结对编程了。然后我们讨论一个学习会议,高级开发人员教初级开发人员如何解决一个特定的问题。

但是如果两个开发人员都在同一水平上,那么在这样的环境下他们能完成的工作是惊人的。这里最大的好处也是两个开发人员互相激励,万一其中一个失去焦点,另一个开发人员会让他重新回到正轨。

总结一下:当两个经验水平相似的开发人员一起解决一个复杂的业务问题时,结对编程工作得很好。

类型2:同步代码审查

第二种类型是同步代码审查。在这里,编码员自己生成代码,并在完成编码后立即要求评审员进行评审。

评审员在她的办公桌前加入编码员,当他们一起评审、讨论和改进代码时,他们看着同一个屏幕。

审查者缺乏知识

当审查者缺乏关于任务目标的知识时,这种类型的代码审查工作得很好。当团队既没有细化会议,也没有适当的冲刺计划会议时,就会发生这种情况,他们会提前讨论每个任务。

这通常会导致只有特定的开发人员知道任务需求的情况。

在这些情况下,在开始复习之前,让复习者了解一下任务的目标是非常有帮助的。

期待大量代码改进

如果由于缺乏来自编码者的经验而期望有很多代码改进,同步代码评审也能很好地工作。

如果一个有经验的高级开发人员将要评审一段由非常初级的开发人员实现的代码,那么当他们在初级开发人员声称他完成后一起进行改进时,评审通常会更快。

强制语境转换的缺点

但是同步代码审查有一个主要的缺点,那就是强制的上下文切换。这不仅让审稿人非常沮丧,还拖慢了整个团队。

事实上,我已经写了一篇关于the 5 major problems with synchronous code reviews

类型3:异步代码审查

然后我们有第三种类型,异步代码审查。这不是在同一个屏幕上同时完成的,而是异步完成的。在编码员完成编码后,她让代码可供审阅,并开始她的下一个任务。

当审查者有时间的时候,他会按照自己的时间表在自己的桌子上审查代码,而不是亲自和编码者交谈,而是使用一些工具写下评论。评审者完成后,工具将通知编码者关于评论和必要的返工。编码员将根据评论改进代码,同样是根据他自己的时间表。

通过使更改可供再次审查,整个周期重新开始。编码器改变代码,直到没有更多的评论需要改进。最后,变更被批准并提交给主分支机构。

正如您所看到的,同步代码评审与异步代码评审的工作方式截然不同。

没有直接依赖关系

异步代码审查的最大好处是它们异步发生。编码员并不直接依赖于评审员,他们都可以按照自己的时间表完成自己的工作。

许多审查周期的缺点

不利的一面是你可能会有许多评审周期,这些周期可能会持续几天,直到评审最终被批准。

当编码完成时,通常需要几个小时,直到审查者开始审查。大多数时候,评审者提出的建议第二天才被编码者修正。

所以第一个周期至少需要一天。如果你有几个这样的周期,那么评审时间会超过一周——这甚至没有考虑编码和测试的时间。

但是有一些选择可以防止这种长时间的失控。例如,在我的团队中,我们制定了一条规则,即每个开发人员在早上拿起任何其他任务之前都要先进行待定的评审。午餐休息后也要做同样的事情。

由于开发人员在长时间的中断后已经脱离了他的上下文,所以您不会强制进行非自然的上下文切换,并且仍然可以在合理的时间内查看代码。

比较这种类型的代码评审的优点和缺点,我认为异步代码评审应该是每个专业开发团队的默认类型。

但是在我告诉你我为什么这么想之前,让我们来看看第四种类型的代码评审。

类型4:偶尔回顾一下代码

很久以前,我通常每个月和整个团队一起进行一次代码审查会议。我们坐在会议室里,一个开发人员正在展示和解释他最近写的一段困难的代码。

其他开发人员试图发现潜在的问题,对如何改进代码进行评论并给出建议。

我不认为任何团队会永远使用偶尔的代码审查方法。我只能想到一种这种类型有意义的情况:当整个团队对代码评审毫无经验时,那么让每个人聚在一个房间里一起做几次评审可能有助于每个人理解代码评审的目的和目标。

然而,从长远来看,第四种类型并不是一种合适的技术,因为让整个团队通过一段代码工作效率相当低。

我应该选择哪种代码审查类型?

所以,现在你可能想知道你应该选择哪种类型。

我们谈到了正式类型,它显然不太流行,在实践中也很少使用..

然后我们讨论了轻量级代码评审的类别,并区分了4种不同的类型。

类型1,即即时代码审查,是在成对编程中完成的,当两个具有相似技能集的开发人员在处理复杂的业务问题时工作得很好。

类型2,同步代码评审,当评审者缺乏任务目标的知识并且需要编码者的解释时,运行良好。如果由于编码器缺乏经验而导致大量代码改进,它也能很好地工作。

但它也有强制上下文切换的缺点,这让审查者感到沮丧,并降低了整个团队的速度。

类型3,异步代码审查,防止了强制上下文切换的问题,并且在最常见的用例中运行良好。

类型4,一次一次的代码评审对于一个专业团队来说并不是一个永久的选择,它可能只用于让一个团队开始进行代码评审。

默认情况下使用异步审阅

我认为专业团队应该将异步代码评审作为默认类型,因为与同步评审相比,它避免了很多缺点。

同步评审可以在评审者不能理解编码者所做的改变的情况下使用。但是在这种情况下,评审员无论如何都会要求编码员做进一步的澄清,如果你在一个团队中工作,这种情况应该很少发生。

如果你没有一个真正的团队和一群人一起工作,那么同步代码评审是有意义的。如果审核者根本不知道你最近几天在做什么,那么在你们一起审核之前给出一个适当的解释是有意义的。

如果你有两个有着相似技能的开发人员,并且正在处理一个复杂的业务问题,那么切换到结对编程是有意义的。但是通常一个团队是由具有多层次经验的人组成的,它不会一直处理复杂的业务问题。大多数时候,你都有一般复杂程度的普通任务。

因此,对于一个专业团队来说,最好的选择是在默认情况下使用异步审查,并在必要时切换到同步类型或成对编程。

好了,今天就到这里。

您的团队使用哪种类型的代码审查?你知道我在这里错过的另一种代码审查吗?那么请在评论中告诉我。

下次再聊。保重,HabbediEhre。