it-swarm.cn

进行代码审查的最有效方法是什么?

我从来没有找到执行代码审查的理想方法,但是我的客户经常需要它们。每个客户似乎都以不同的方式来做他们,而我从未对他们中的任何一个感到满意。

您执行代码审查的最有效方法是什么?

例如:

  • 是一个人被认为是质量的守门员并审查代码,还是团队拥有该标准?
  • 您是否使用投影仪作为团队练习来检查代码?
  • 是亲自完成,通过电子邮件还是使用工具完成的?
  • 您是否避免使用对编程和集体代码所有权等评论来确保代码质量?
71
Paddyslacker

在我的工作中,我们有一个非常简单的规则:在合并或提交到主干之前,更改必须至少由其他开发人员进行审查。在我们的情况下,这意味着其他人实际坐在您的计算机旁,并浏览更改列表。这不是一个完美的系统,但是它仍然显着提高了代码质量。

如果您知道要检查您的代码,这将迫使您首先查看它。那时许多问题变得显而易见。在我们的系统下,您必须向审阅者解释您做了什么,这又使您注意到以前可能遗漏的问题。另外,如果您的代码中的某些内容对于审阅者而言不是立即清除的,则表明您需要一个更好的名称,注释或重构。并且,当然,审阅者也可能会发现问题。此外,除了查看更改之外,审阅者还可能注意到附近代码中的问题。

该系统有两个主要缺点。当变化不大时,对其进行审查几乎没有意义。但是,我们绝对必须遵守规则,以避免在声明更改不“琐碎”的情况下溜溜溜。另一方面,这不是检查系统的重大更改或添加新的大型组件的好方法。

之前,我们曾尝试进行更正式的审查,当时一位开发人员将通过电子邮件发送代码以将其审查给团队的其他成员,然后整个团队将聚在一起讨论。这花费了每个人很多时间,结果这些审查很少而且相去甚远,而且只有一小部分代码库得到审查。 “另一个人在提交之前检查更改”对我们来说要好得多。

32
Dima

我喜欢代码审查,尽管可能会很痛苦。我喜欢它们的原因是,他们对代码和其他观点有更多的关注。我相信,即使使用结对编程,也应检查代码。两个人在同一个代码上共同犯下相同的错误就很容易了,不同的眼睛可能不会错过。

如果与放映机作为一个小组一起完成,则确实应该逐个进行审查之前会议。否则,那只是时间的烦人。

我只通过电子邮件和小组方式进行过代码审查。一般来说,我不认为应该亲自进行。当有人抬头看着你的代码时,您会感到有些压力。我确实相信为代码检查而设计的工具将是一项很好的资产,因为它可以帮助解决一些平凡的方面,并且与通过电子邮件相比,它应该更容易标记代码的问题位。

一个人进行所有代码审查的问题在于这可能是一个瓶颈。有了充分记录和设计的编码标准,就没有必要了。根据环境/发布时间表,始终让某人作为备用代码审阅者可能是一个好主意。

我确实相信代码所有权是个好主意,因为该人员可以将理解该代码作为其优先事项,并可能扮演看门人的角色。

13
George Marian

SmartBear ,我们不仅制作了 代码审查工具 ,而且每天都在使用它。这是我们开发过程中必不可少的一部分。我们会检查所有已签入的更改。

我认为拥有一个网守代码审查员是一个坏主意,这有很多原因。这个人成为瓶颈,他们必须进行过多的代码审查(只是为了保持项目进展),才能真正发挥作用(每次限制60-90分钟是有效的)。代码审查是共享想法和知识的好方法。无论您的看门人有多少超级巨星,他们都可以向团队中的其他人学习。同样,让每个人都进行代码审查也会创建一个“集体代码所有权”环境-人们会觉得自己拥有代码的质量(不仅仅是质量保证或关守)。

我们提供了有关“ 对等代码审查的最佳实践 ”的免费白皮书,其中包含11条使代码审查有效的技巧。其中大部分内容与约翰以提炼形式提及的书中的内容相同。

6
Brandon DuRette

别找借口。练习配对编程。它可能是最好的代码审查。任何其他机制都会导致责备游戏。结对编程会激发团队合作精神和集体所有权。此外,您还需要与一对讨论想法,快速失败,采取纠正措施,只有对编码和审阅过的代码才会提交给配置管理系统(CMS)。幸福的一对编程!

3
karthiks

我参与的代码审查中尝试做的一件事是亲自审查代码后,我使用Findbugs,PMD,JavaNCCP等工具对代码进行静态分析,并查看这些工具在内部发现的任何问题。要检查的代码。我特别希望查看具有异常高级别复杂性的任何内容,请他们解释为什么必须具有这种复杂性级别,或者为什么建议的漏洞并不重要。

青年汽车

2
mezmo

在我目前工作的地方,我们生产硬件设备以及与其连接的软件,这些软件已进入关键基础架构。因此,我们非常重视发布质量。我们使用 Fagan Inspection 的变体,并有一个正式的审核流程。我们已通过ISO 9001认证,还有其他认证。

关键基础设施行业对其可靠性和可重复性非常感兴趣。 :-)

2
Paul Nathan

如果您不进行结对编程,我建议使用代码审查。

不必争论配对的优缺点,但是很难对(至少)另一个人不断检查您的代码的积极作用提出质疑。该代码甚至由(至少)两个程序员编写和设计-几乎没有比这更好的了。我之所以说“至少”是因为imo,您应该尝试切换对很多,这样每个人都可以尝试使用代码。

2
Martin Wickman

在我公司,我们有针对初级程序员的强制性代码审查,以及针对高级程序员的自愿性代码审查。没有指定的代码审阅者,审阅请求将发送给所有开发人员。

该系统运行良好-在时间允许的情况下进行审核,并且可以通过几组眼球来审核更改。

优秀而免费的 Review Board 工具对我们来说非常有效,并且被证明是传达评论的绝佳方式。

2
GavinH

如果您正在从事一个由多个人组成代码库的项目,则需要建立一个标准。

在这一点上,根据我的经验,最好将一个人指定为代码检查的“王者”,如果您愿意并且他/她说了什么。在这方面,如果一个用户不遵守标准,则国王会照顾它。

作为一名开发人员,我多次审查自己的代码,以使其可读,明智和其他所有内容。通常,我们使用Javadoc或类似的语言编写代码,并使用@author标记将所有权附加到函数,类等上。

如果功能不正确,我们会与所有者交谈,与类等交谈。

2
Chris

在我公司,每个任务都分配了一个测试员来测试任务,还分配了一个代码审查员来审查代码。

如果您的产品已经发布,并且想要确保您没有做错任何事情(例如句柄泄漏或内存泄漏),那么代码审查是一件好事。我认为在发布产品之前的初始开发过程中,代码审查可能会做太多工作。

如果您的团队有所有高级开发人员,那么同行评审仍然很有用。有时每个人都会犯错误。如果您的团队有一些高级职员和一些初级职员,那么让高级开发人员进行代码审查,但同时也对高级职员的代码进行代码审查。

关于代码审查的重要一件事是它可以捕获我们所犯的错误,但是它不能代替测试。

2
Brian R. Bondy

我们发现执行代码审查的最有效方法是使用github来显示分支中的差异的一对一。


  • 是一个人被认为是质量的守门员并审查代码,还是团队拥有该标准?

    • 取决于团队的规模-3人的团队将拥有1名具有良好实践知识的高级职员,而12人的团队可能会由3或4个人担任此职务。
  • 您是否使用投影仪作为团队练习来检查代码?

    • 亲自。 1对1威胁较小。有时为了获得知识而在公共区域进行。取决于确切的情况,人员,时间表等。
  • 是亲自完成,通过电子邮件还是使用工具完成的?

    • 亲自。我们使用git和github,它具有出色的代码审查和diff比较工具,可简化代码审查。
  • 您是否避免使用对编程和集体代码所有权等评论来确保代码质量?

    • 我们会尝试同时做这两者。这意味着当遇到特别棘手的问题时,或者在核心基础结构上工作时,或者在准备休假或离开公司时,可以进行配对以共享和转让知识。最后,大多数代码或仅包含外观更改的代码也应进行审查。

与所有编码项一样,正确答案应考虑到:

  • 公司类型(例如,初创公司与大型公司)
  • 公司规模
  • 开发人数
  • 预算
  • 大体时间
  • 工作量
  • 代码复杂度
  • 审稿人的能力
  • 审阅者的可用性
1
Michael Durrant

在我公司中,除非签约我们正在修改一些非常关键的产品并且没有时间执行我们的标准质量检查流程,否则我们永远不会在签入之前进行正式的代码审查。

我们要做的是,每当我们觉得对代码进行回顾都会有用,我们在修改后的代码中添加“ // todo:对joe进行代码审查”注释。通常,我们选择Joe是因为他拥有修改后的代码,但如果此选择标准不适用(通常如此),我们只是随机选择其他人。当然,如果乔那时恰好有空,我们将使用旧的“肩上审阅”方法。

作为审阅者,您唯一需要做的就是定期在整个代码中搜索“ // todo:我进行的代码审阅”,查看所做的更改,然后在不包含“要做...”评论

如果有问题,我们将改回传统的通讯方式(邮件/聊天/等)。

此方法为我们提供了我们要在审查系统中寻求的两个主要素质:

  • 头顶很轻
  • 可追溯性
1
Brann

我曾在许多公司工作过,看到过许多流程。我目前的团队正在处理迄今为止我所见过的最好的团队。

我们使用敏捷的开发过程,在此过程中,我们需要每个故事都要经历的大门。这些门之一就是代码审查。在完成代码审查之前,故事不会继续进行测试。

另外,我们将代码存储在github.com中。因此,在开发人员完成更改后,他们将链接发布到故事中的提交。

然后,我们标记其他开发人员进行审核。 Github有一个注释系统,允许某人在相关代码行中注释。 Github然后向发行版发送电子邮件,因此有时我们实际上会吸引我们其他一些团队的关注。

这个过程对我们来说非常有效。我们确实使用了一个敏捷的过程工具,该工具使发布提交变得容易并且促进了沟通。

如果问题特别棘手,我们将坐下来讨论。之所以行之有效,是因为它是我们流程不可或缺的一部分,每个人都对流程的运作方式有所认同。如果代码审查导致需要的返工,我们可以将工单移回进行中,然后在进行更改后可以再次进行审查,或者审查者可能会注意到故事中的问题已解决,而无需再次审查。

如果测试可以解决问题,它将一直持续到进行中,并且还会审查任何进一步的更改。

0
Bill Leeper