问让所有开发人员进行代码评审。

EN

我们不选评论员。

在我们的团队中：

• 在完成拉请求之前，必须对所有代码更改进行代码检查。
• 至少有一个开发人员必须进行代码评审(两个或两个以上的评审人员更好，让测试人员、分析人员和其他团队成员进行代码评审也非常有益)。

没有分配代码评审，当它对他们起作用时，人们会捡起它们。我们的理解是，我们不能把故事推倒在管道里。有时有人会提到，他们正在等待一个CR站，但仅此而已。

我喜欢这种模式，它让人们尽可能地拿起东西，避免“给人工作”。

引入一条规则，即错误可能被分配用于修复，不仅是那些提交了更改的人，而且是那些检查它的人。这将为代码评审创建正确的透视图。

至于,

你认为代码审查员应该因为他们花在(好的)代码评审上的时间而得到奖励吗？

嗯，我不知道一般来说，除了拿薪水和为自己所做的事情感到骄傲之外，开发人员做他们的工作会得到多大的回报。但是，由于审阅代码是他们工作的一部分，审查员应该有时间进行评审，并以某种方式分享这一荣誉。

您遇到的主要问题不是技术问题，但有些工具可以降低代码评审所需的工作量。有几个挑战需要克服：

• 了解变化是什么。Git在特性分支上拉动请求确实有助于这一过程。
• 让代码评审一个人们必须在同一个房间里的事件。这增加了调度、会议资源等方面的压力。GitHub、GitLab和BitBucket允许异步评审，以便在对等方准备就绪时进行。
• 在查看代码时提供有意义的反馈的能力。老实说，GitHub、GitLab、Bitbucket拉请求中的逐行评论功能确实比面对面的会议更有用。感觉不那么有政治色彩。

这并不是说您不能使用SubVersion或其他工具(如Fisheye)来帮助您，但是内置于Git管道中的与特性分支的集成确实减少了这项工作的工作量。

除了工具之外，您还需要看到更多的社会挑战：

• 让您的开发人员通过检查任何打开的拉请求来开始他们的一天。
• 让开发人员在启动新任务之前检查任何打开的拉请求。
• 需要一个以上的人批准您的拉请求。

同样值得检查的是，哪些类型的任务正在被更多参与的人检查代码。他们可能会抓住所有容易的评论，这会让其他人更痛苦。