我怀疑主要代码审查会掩盖我的团队。太多的代码审阅合并而没有任何注释。

在我看来，没有评论就没有代码评论。

作为团队的领导者，我如何才能正确地监视我的团队正在执行正确的代码审查过程，以及如何帮助他们最大化过程的收益？

更新资料

以为人们可能想知道任何更新。我尝试了很多在这里给出的建议。大多数已经在使用中。有些帮助。但是，问题仍然存在-当我不看时，有些人不断收到错误代码。

我发现代码审查监视没有提供给我的团队工具以使他们的代码从一开始就更好的帮助。

因此，我添加了一个名为“ jscpd”的库来检测复制粘贴。复制粘贴时构建失败。这立即消除了一个问题。

接下来，我们将尝试代码气候。

我还要对旧代码审查进行一次人工审查，每次冲刺需要半天。我正在将todos 转换为问题/票证-我发现人们正在写它们，但以后再也不会处理它们。我还将与整个团队开会，以在适当时检查代码。

总的来说，我们在朝着正确的方向前进。

我将提供与我的其他答复者不同的观点。他们是对的-如果您想了解事情的进展，请参与。如果您想要更多的可跟踪性，可以使用一些工具。

但是根据我的经验，我怀疑还有其他情况。

您是否考虑过您的团队可能觉得该过程对于大多数提交来说都是无效的/愚蠢的/无效的？请记住，过程是在记录有效的方法，而不是要遵守的规则。作为团队的领导，您可以在那里帮助他们做到最好，而不是执行规则。

因此，在回顾中（如果敏捷）或一对一（如果您是经理）或在随机即席走廊会议中（如果您是非敏捷团队负责人，并且有另一位经理在一对一地进行），请提出回顾。询问人们对代码审查过程的看法。如何运作？怎么不行 假设您认为这可能不会给团队带来最大的好处。确保听。

您可以在这些会议中倡导代码审查，但是最好听取反馈。最有可能的是，您会发现您的团队认为“适当”的流程需要调整，或者存在某些根本原因（时间压力，缺少审阅者，Bob只是提交了自己的代码，所以我们为什么不能解决） 。

在中断的流程之上强制使用工具不会使流程变得更好。

我不喜欢发布单行答案，但这似乎很合适：

参与过程。

获取一个工具，例如ReviewBoard或Redmine的codereview插件。然后，将每个审阅创建为必须由某人关闭或评论的任务（就像错误单一样）。然后，您可以追溯谁创建了审核票证，以及谁关闭了该票证。您可以将审阅票据与源代码签入绑定在一起，即从修订版本创建票据。

几件事（说实话，答案中大部分都涵盖了这些内容，但我想将它们放在一个地方）

• 您可以将流程和规则放在适当的位置，以确保进行代码审查，但是将它们放置在其中几乎是不可能的，因此，代码审查实际上不仅仅是框选式练习。最终，如果团队要有效地利用流程，则必须看到流程的好处

• 以身作则。参加评论。作为开发人员，如果我的经理（现在是非开发人员）发现我没有的东西，我会感到很难过。突出显示应该被审查的问题（以非责备的方式）。如果发生生产问题，或者在质量检查过程中出现问题（如果您有单独的质量检查流程），请突出显示可能在代码审查中发现的问题。与团队讨论如何我们可以保证这样是抓住未来的问题

• 与团队讨论他们希望流程做什么。如果他们看不到它的任何意义（一开始可能会发生），请使用生产问题和必要的修复措施来证明它的好处

• 使用Sonarqube之类的自动代码检查软件，以便代码审查可以专注于无法理解的代码，逻辑错误，缺少文档等问题。

您可以在与开发人员讨论并同意的代码审查中记录团队的需求。您可以在代码审查中考虑的一些事项包括：

• 检查代码是否符合预期要求，即符合要求

• 代码样式，以确保开发人员以一致的样式进行编码

• 优化，例如函数调用数

• 架构和可重用性

• 异常处理和记录

• 技术债务：代码处于比开发人员开始工作时更好的状态

• 签出并构建代码（我觉得这很有用，但是我团队中的其他开发人员更喜欢将其留给测试人员使用）

• 使用自动化工具（我使用过SonarQube）。我发现将其集成到您的构建过程中以加强对代码的改进（例如增加测试范围）很有用

自动化工具可以涵盖上述某些步骤，但是当您尝试改善代码检查或完成代码检查的方式时，同时使用该工具和眼球检查可能值得。但是，防止技术债务的最重要步骤（架构和可重用性）不能完全自动化。

如果您的团队在应用此方法时前后不一致，则可以尝试仅允许正确执行代码审查的开发人员具有合并权限。例如，您可能只想从团队的主要开发人员入手。使用这种方法的权衡是那些开发人员可能成为开发过程中的瓶颈，因此您和团队需要决定是否要这样做。我个人会接受这种权衡，并且通过代码审查可以增加团队其他成员的纪律，然后在准备就绪时可以增加拥有合并权限的开发人员的数量。

最后，值得评论。因此，每周一次与开发人员聚会，并建设性地讨论这些评论以及改进它们的方法。

我将告诉您我的团队如何将代码审查快速集成到其工作流程中。

首先，让我问一个问题。您是否正在使用版本控制系统（例如Mercurial，Git）？

如果您的答案是肯定的，请继续。

1. 禁止每个人直接将任何东西（甚至小补丁）直接推送到主分支（主干）*
2. 在单独的分支机构中开发新功能（或修复程序）
3. 当开发人员认为分支已准备好集成到master中时，他们将创建“拉取请求”
4. 禁止所有人合并自己的拉取请求*
5. 让另一个开发人员评估拉取请求并查看新代码
6. 如果代码通过审核，则良好，可以合并拉取请求，否则可以应用修复程序
7. 重复步骤6，直到代码足够成熟为止（无需重新开始即可完成）**
8. 完成后，您的所有新代码都会（至少是摘要）由具有名称的人进行审核

现在，您在工作流程中有了一个精确的点，可以完成代码审查。

在那儿行动。

*可以通过服务器端挂钩自动执行

** GitHub（及其他）完全支持此过程，并且相当易于使用，请查看

我认为您应该创建一个模板，并要求您的团队成员在每次进行代码审查时对其进行更新。但是即使如此，您仍应最初参与审核过程。