分配给代码审查的时间

如果您正在执行代码审查

• 与实施相比，您在代码审查上花费了多少时间？
• 有多少更改需要进行代码审查？
• 您认为应该很多/应该更多吗？

是否有关于有效性的研究？

[edit]谢谢大家的回答，很难为这样的问题选择“赢家”，其他答复中也有很多有价值的信息。

在我的工作中，我们执行以下代码审查程序。到目前为止，它对我们来说效果很好，我们发现它非常省时，尤其是在工时方面。我们实际上没有为审核分配任何具体时间。对主干的每次提交或合并都必须进行审查，并且审查者需要花费很长的时间。

编辑：花费的时间当然取决于更改的幅度。小功能和错误修复需要几分钟的时间。影响系统许多部分的大型新功能，重构或更改可能需要半天的时间进行审核，而另一天需要解决所有由此产生的问题。

为了使该系统正常工作，至关重要的是经常提交中继，以使更改具有可管理的大小。当您必须查看某人的一年代码时，您不想遇到这种情况。

在学习方面，Smart Bear软件将免费为您发送一本小书，《同行代码审查的最佳保留的秘密》。它包含许多有关代码审查各个方面的文章，包括有关应花费多少时间以及它们如何有效的研究。

在我们的项目中，系统的每项重大更改都将由团队负责人或与其他将成为新模块主要“消费者”的开发人员一起进行审查。我们谈论的是Skype，或者在Emacs中使用Rudel（用于协作编辑的插件，基本上它允许多个用户实时编辑同一文件），或者使用TypeWith.me（Piratepad），或者我们中的一个在skype中共享他的屏幕。

很难对此进行量化，因为世俗的变化（例如新视图，页面等）不会得到审查。我们确实审查了新模块，主要更新和重构。至于重大更改，代码审查可能需要10％到30％的时间，但这是值得的。

我可以说成对编程，当两个程序员同时编辑同一文件时，不仅仅是坐在同一台计算机上，这比坐在办公室里的通常的办公实践要好得多。

对于诸如命名约定和范围错误之类的简单事情，我们使用我们自己的或开源的自动工具（jslint，pylint，pyflakes，pep8）。而且我们不限制提交和推送：我们使用Mercurial，它具有非常容易的分支和合并（我必须说，比在Git中更容易）。错误不是代码审查的问题。

我们举行团队会议，宣布变更和新事物，但并不是每个人都真正关注。可能我们应该做更多的代码审查。

没有正确或错误的答案。但是正如我之前所建议的那样-如果代码审核是由外部团队成员[强烈推荐的方法]完成的，则可能占开发工作的大约30％至35％。但是，如果这是由属于开发团队的内部项目团队成员完成的（不推荐），则可以在大约20％的时间内完成的开发时间。

注意：我在搜索其他内容时遇到了这个线程，我认为我可以在这里添加一些值。顺便说一句，以上所有这些工作量估算都是基于我在多个项目中担任项目经理的工作经验。希望能帮助到你。

每个组织和代码库都不同，因此很难获得整个行业的价值。
如果您真的很认真，则应该开始收集指标。即进行代码检查，直到满意地完成包括返工为止。开始将其收集到数据库中（LOC，代码复杂性，编程语言，时间等）。然后在测试期间还收集有关缺陷率的指标。只要您可以减少此代码审查，就应该自己付费。如果缺陷从测试中返回，则收集有关花费了多少时间来修复缺陷的度量。在您的组织中建立这些数据，创建基准，您就可以非常准确地预测它们。寻求进一步学习的术语是质量成本和质量差的成本。

唯一的警告是，这可能开始变得官僚主义，并取决于组织文化。