为代码评审分配人员

Question

我的团队在代码评审方面有问题。

每个人都在忙着自己的任务，只有少数的开发人员每天都会进行审查。由于每个合并请求都需要2次批准，其中一些请求在审查中停留了几天，如果不是几个星期(!)，这会减缓项目的进度。每个人都明白它的重要性，但都有自己的借口。

如何指派人员进行代码评审，或者给他们提供更多的帮助？

Answer 1

问题似乎从计划开始。当您确定团队承担给定工作的能力时，您应该考虑到同行评审所完成的工作所需的时间(除了完成工作所需的其他一切)。在合并工作之前，人们太忙，无法完成所需的评审，这种想法是上游问题的征兆，在规划和评估中。我将更多地思考你在这些领域所做的工作，以及为提高这些领域的效力可以做些什么。

另一件需要考虑的事情是，为什么你需要2次批准。我对这项工作有更多的信心，但这是什么成就呢？这在某种程度上可以追溯到计划和评估，但通过理解谁可能需要审查一项工作，并确保正确的人员对其进行审查，可以缓解一些瓶颈。

我不认为您应该查看您的评审和合并过程中的解决方案，而是应该考虑上游活动和团队的总体纪律，以确定工作的定义、定义工作的意义、估计工作的努力、计划团队的能力，并相互承诺完成任务。

Answer 2

啊，“我忙着开发代码审查”的谬论。

好的，代码评审是开发的--仅仅因为它本身并不是您的特性，就不会影响它。

最终每个人都会受苦。建立一种首先对代码评审进行排序的文化并不简单，但这是必要的。

因此，如果只分配支持问题可能会影响代码评审，那么代码评审就是首要任务。它是评审的回报--任何任务都必须通过发布管道加以推广--这本身就是动机。一个好的团队应该理解相互审查工作的重要性--甚至不必等到正式的代码评审才能完成。

您的开发任务只有在生产中才能完成。

从来没有真正的“没有时间”去做某事，只是挪用了现有的东西。当你正在经历整个过程的放缓是造成“太忙”的部分原因。因此，它的这一部分造成了自己的问题。

这其中的一些可能取决于您的团队规模，但如果您有每天的僵局，没有人真正喜欢这些。我是一名高级开发人员，但我仍然站起来，去和从事我将要复习的工作的人交谈，看看进展如何--尤其是如果这是我熟悉的事情。任何你认为资深的人也应该这样做--角色之一就是对整个过程感兴趣，同时培养更多的初级员工。我个人也发现，打破我正在做的事情是有帮助的，因为敲打键盘不是发展中最重要的部分--它是在思考你将要做什么。如果这是您的开发人员所处的操作模式，那么他们也需要重新考虑这一点。

Answer 3

我建议你采取看板的方法。例：

   +----------------------------------+
   |todo    |dev     |coderev |done   |
   |        |max 3   |max 3   |       |
   +----------------------------------+
   |task 7  |task 4  |task 1  |       |
   |        |task 5  |task 2  |       |
   |        |task 6  |task 3  |       |
   +----------------------------------+

看板的关键是每个列都有一个限制。如果列已满，则不允许将任务移动到其中。这是为了突出生产中的瓶颈，并表明哪里需要更多的能力。

因此，在这种情况下，开发人员刚刚完成了任务4。他们必须做的下一件事是将任务移到代码评审阶段。但他们是不允许的！

由于dev列也已满，因此无法将任务7拾取并移动到dev。所以他们别无选择。

在第二天早上站起来时，任何被阻塞的开发人员都必须从开发转向代码评审。

一旦完成了代码评审，列就会被释放，任务可以再次流动。