让所有开发人员进行代码审查


13

我是7-8个开发人员团队中的软件开发人员。我们已经进行了一段时间的代码审查,并且随着时间的推移,代码质量也有所提高。

但是我最近注意到,与其他开发人员相比,一些开发人员被要求进行更多的代码审查。恐怕是因为他们态度灵活。

在我看来,这不是应该执行代码审查的方式:所有团队都应对此负责,并且不应因为愿意接受更改而选择代码审查者。

您如何处理团队中的这个问题?

您是否建立了选择代码审查者的规则?

您认为代码审查者应该花时间进行(良好)代码审查而获得报酬吗?以及如何获得奖励?

感谢您的回答/想法。


7
您是否考虑过创建一个轮循机制,使编码员对谁在审核中一无所知,而审稿人对谁是编码员一无所知?
尼尔

1
我还没有,但是我喜欢这个主意!谢谢!
guillaumegallois '18年

1
谁负责,他们为什么不做他们的工作,这应该包括确保其他人都在做他们的工作?
JeffO '18年

在我的团队中,每当拉出请求时,都会自动分配审阅者。审阅者是从团队循环中选出的。我们为每个存储库都有一个Webhook,可在打开PR时自动分配审阅者。它基本上保留了所有开发人员的列表,以及最后分配的人员,并在列表中进行工作。
丹·琼斯,

Answers:


12

我们不选择评论者。

在我们的团队中:

  • 在请求请求完成之前,必须对所有代码更改进行代码审查。
  • 至少一名开发人员必须进行代码审查(两个或多个审查员更好,并且让测试人员,分析师和其他团队成员进行代码审查也非常有益)

未分配代码审查,当代码审查对他们有用时,人们会选择它们。我们的理解是,我们无法通过管道推送故事。有时,有人会提到他们正在等待站立式CR,但这仅此而已。

我喜欢这种模型,它使人们能够选择并避免“给人们工作”。


6

引入一个规则,即不仅可以将错误分配给修复者,而且还可以将错误分配给修复者。那应该为代码检查创建正确的视角。

至于,

您认为代码审查者应该花时间进行(良好)代码审查而获得报酬吗?

好吧,我不确定开发人员除获得薪水并为自己所做的工作感到自豪之外,通常会因自己的工作而获得酬劳。但是,由于审阅代码是他们工作的一部分,因此审阅者应该花时间进行审阅,并以某种方式分享功劳。


2
这是一个有趣的想法,但是很多时候出现错误时,90%的工作正在准确地找出导致错误的原因,而10%的工作正在修复它。进行尸检以确切找出导致错误的更改是什么都不会发生,除非它有助于弄清正在发生的事情或如何进行安全修复。
DaveG '18年

您对应该给予代码审查者的功劳很好。这绝对是一个应该解决的问题。感谢您的回答!
guillaumegallois '18年

我认为这可能会导致人们尝试完全不进行代码审查,或者可能因为人们开始挑剔而没有完成任何工作。
Mateusz

5
该答案假设代码审查的目的是发现错误。事实并非如此,主要目的是使代码保持在可维护和可发展的状态(如果幸运的话,还会发现一些错误)。
布朗

@DocBrown可以防止错误,并确保以后修复该错误会更快(通过使其他开发人员熟悉该代码并确保该代码编写正确)
max630 '18

4

您遇到的主要问题不是技术问题,而是某些工具可以减少代码审查所需的工作量。有一些挑战需要克服:

  • 了解变化是什么。功能分支上的Git Pull Requests确实可以帮助完成此过程。
  • 使代码审查人员必须在同一房间的事件。这增加了日程安排,会议资源等方面的压力。GitHub,GitLab和BitBucket允许异步审核,以便在对等方准备就绪时可以进行审核。
  • 查看代码时提供有意义的反馈的能力。老实说,GitHub,GitLab,Bitbucket拉取请求中的逐行注释功能确实比面对面会议更有用。感觉不那么政治。

并不是说您不能使用SubVersion或其他工具(例如Fisheye)来提供帮助,但是Git管道与功能分支的内置集成确实使这项工作变得很轻松。

在工具之外,您需要研究更多的社会挑战:

  • 让开发人员通过审查所有未完成的请求来开始新的一天。
  • 让您的开发人员在开始新任务之前查看所有打开的请求请求
  • 您的拉取请求需要一个以上的人的批准。

也可能需要检查哪些类型的任务正在由敬业度较高的人员进行代码审查。他们可能会抓住所有容易的评论,这会使其他所有人感到痛苦。


最后一点是好的。我曾经在一个小团队中与一名开发人员一起工作,该开发人员只会审查对他编写的软件所做的更改,这些更改导致团队其他地方出现严重的瓶颈。
罗比·迪

在这种情况下,听起来您好像有人试图保护他们的“领土”。您想尽可能地增强代码的社区主人翁感。换句话说,代码中没有没有“除福”以外的其他开发人员无法接触的保护区。我知道是否存在专业差距,您无法审查数学,但是您至少可以审查代码与意图的匹配程度。
Berin Loritsch '18

2

一个好主意是按循环方式进行-选择一个对代码检查最少的人。随着时间的流逝,团队中的每个人都应该进行大致相同数量的评论。它也传播知识。

显然,偶尔会有例外,例如假期,那里会有高峰和低谷。

大三和大四/领导之间应该没有区别。应该对每个人的代码进行代码审查-无论他们有多高级。它减少了摩擦并有助于共享不同的方法。

如果您仍然担心所有这些检查的质量,请考虑为通过代码检查引入一套最低标准。您所包括的内容完全取决于您,但是您可能需要考虑的内容包括代码覆盖率,单元测试,删除注释掉的代码,度量,足够的注释,构建质量,SOLID原则,DRY,KISS等。

对于激励代码审查,质量代码奖励。我敢肯定我们已经在次优的代码基础上进行了工作,如果另一位开发人员从一开始就对代码进行一次建议并提出建设性的建议,则可以大大减轻痛苦。


0

听起来团队缺少正式的代码审查流程。

我不是在谈论创建一个350页的Word文档,而是关于过程所需要的一些简单要点。

重要的位:

  1. 定义一组核心的审阅者。没有一般性陈述。命名人物。

    这些应该是您的高级开发人员。

  2. 需要超过1位核心审核者才能退出该审核。

  3. 在每个sprint或发行版中至少确定另外一名非核心审阅者是临时核心审阅者。在此期间要求所有代码审核均退出。

项目#3允许其他开发人员轮流进入核心审阅者组。几周后,他们将在评论上花费更多的时间。这是一种平衡的行为。

至于奖励人呢?很多时候都承认一个人在整个团队面前进行代码审查时所做的努力可以奏效,但不要为此烦恼。

如有疑问,请定义流程,并告知团队他们需要坚持执行。

您可以尝试的最后一件事-可能引起争议:如果我可以使用成语,让@#$%成为粉丝。

让团队失败,因为未遵循代码审查过程。管理将介入,然后人们将改变。在您已经定义了流程而团队拒绝遵守流程的最极端情况下,这实际上只是一个好主意。如果您无权解雇人员或对人员进行纪律处分(大多数首席开发人员没有),那么您需要让某个可以这样做的人参与进来。

没有什么比没有改变事物的失败更重要了。尽管人们可能会说些什么,但您可以操纵《泰坦尼克号》,但要等它撞上冰山之前。

有时,您只需要让《泰坦尼克号》击中冰山堡即可。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.