浏览stackoverflow时，我注意到许多帖子，指出一些开发人员在签到MAIN之前主张进行代码审查。但是，这真的可以执行吗？如果是这样，是否一定会减少由于涉及的开销增加而导致代码重构的可能性？

就个人而言，我更喜欢采用持续集成的方法来捕获任何破坏构建的人，然后在大量工作结束时以更粗粒度的方式执行代码审查。我不要求对小型重构进行代码审查。

我很想听听意见。

解决方案

我认为，每次签入时都应该对代码进行审查。修复问题的成本在树中上升了很多。

这可能取决于审核的类型。如果我们谈论的是可能需要数小时/数天的计划和设置的正式检查，那么我认为签入是可以的。如果商店采用了更多非正式的评论/行事方式，则应使它们尽可能轻松，并强制所有代码在签入之前进行审查。

如果评论涉及"增加的开销"，那么我们是对的，我们可能不希望在检查之前强制执行评论。如果评论较为非正式，那么我建议我们执行签前审查政策。

要考虑的另一件事是结对编程。这为我们提供了更加即时的反馈，我们在编写代码时便会对其进行回顾。这是它最大的优点之一。

当然，如果我们不想这样做，建议我们不要在入住政策之前进行审查。如果我们觉得自己很糟糕，那么我们可能需要进行一些补救培训。

我倾向于在停机时以及在返回代码以修复/更改问题时偶尔进行审核。

我认为消除每次检查之前的代码审查开销的最佳方法是使开发人员可以进行配对编程。除此之外，我们还可以指定一个团队成员作为X特定项目模块的正式审阅者。而且这个人每天可以进行更深入的评论。

我们每周举行一次午餐会议，以审查我们在前一周编写的代码。我们通常会尝试确保在迭代完成之前检查作为迭代一部分而更改的代码。这样，开发人员可以在几天后做出建议的更改，然后才能交付最终功能。

我们发现，由于我们定期(每周一次)查看准则，因此通常需要进行的更改很小，可以很快实施。

补充：我们使用FxCop来自动检查每个版本的代码。因此，我们的审查更多是围绕方法，框架使用情况，结构等方面进行的。

每次完成一项功能时(请确保将其安排为该功能的任务之一！)。

代码检查每次签入都是非常糟糕的，我想每小时或者什至更多次检查一次，而不断进行代码检查是不可能的。此外，签入时不必担心的主要问题是确保我们不破坏任何现有代码，并且90％的时间不需要CR。

在处理不熟练的现有代码时，我们可能会要求人们快速进行3分钟的细致检查，然后再进行检入，这对于测试覆盖率低于最佳代码的项目尤其重要(这样的项目，即使所有单元/集成测试都通过了，我们仍然不知道代码是否不错)。

如果我们设置版本控制以将差异发送给所有开发人员，则他们将有机会半自动执行"较小的审核"。

Personally, I prefer the approach of
  employing continuous integration to
  catch anyone who breaks the build, and
  then perform code reviews on a more
  coarse-grained basis at the end of a
  significant piece of work. I don't
  mandate code reviews for minor
  refactorings.

我的感觉是一样的。对我来说，代码审查是对某些代码单元(而非逐步更改)的质量检查和学习经验。向他人学习与代码审查的其他好处一样重要。我从中学到的任何评论。

结对编程并不总是可行也不可取；人们需要时间思考和工作不间断。此外，查看每个提交而不是较大的变更集会导致难以处理和理解的巨大提交(更少的提交==更少的评论==开发人员在会议上花费的时间更少)。

我们希望开发人员经常提交。坚持提交不会破坏构建并不是没有道理的，但是作为功能开发人员，我们希望提交许多小的逻辑进展。分布式版本控制系统可以在这里提供帮助。

在一个有明确资历的小团队中，我发现每天花费30分钟阅读来自源代码管理的差异是相当有效的。在我的博客中对此进行了描述。

否则，我们将需要一些工具支持(例如，坩埚)。安排会议并在投影机上进行检查太痛苦了；我们将停止这样做。

我以前投票。失败失败=失败失败。

等到我们弄坏东西来解决问题时，问题在于它仅适用于小型团队。如果我们有大型团队，那么某天在某天发生问题的可能性就会上升(考虑到一支100人的团队，平均每年要破坏的构建缺陷率为0.5 / dev ， 每周)。

另外，就保持高代码质量而言，提高代码质量的最佳时间是在其最易延展的时间(即签入之前)。

• 对于直接进入main的签入，通常适合每个签入进行代码审查。 Main中的每次构建中断都会对所有通过Main工作的开发人员产生重大影响。
• 在产品出厂前的最后一周，当缺陷接受的门槛很高时，不仅应审查所有变更，而且还应仅由指定的高级开发人员进行审查，以进一步降低变更风险。

在我目前的公司中，如果(a)提交者是高级开发人员，并且(b)等待审查会对其他人产生重大影响，我们有时会允许进行签到后审查。例如，某人在晚上10点进行修复。等到早上才进行签入可能会影响其他开发人员以及自动测试和质量检查本身。我们将缺陷/任务项目输入给另一个开发人员，以要求他们进行审查。这样一来，审核就不会被遗忘。

尽快并尽可能频繁地检入代码。代码审查越早，代码更改的时间就越好。不要让质量控制和过程拖延生产力。代码审查是为开发人员而不是代码审查的开发人员进行的。

这完全取决于组织设置方式。

对于小型团队，我建议的策略是所有签到都应直接发送到主干，差异应发送到团队，并且所有签到应由团队从这些差异中进行审核。这几乎没有开销，并且鼓励进行许多小型签入(更易于通过电子邮件查看)。根据小组，我们可能会感觉到轮换谁在任何给定时间主要负责检查代码。然后，我们可以进行分支测试的发布，从主干中释放出来，将其发送给质量检查人员，然后在质量检查人员批准后发布到生产环境。

较大的团队可能在多个分支机构进行开发。根据组织方式，我们有机会在签入(适用于结对编程)，合并之前(实际上是有多少个开源项目在工作)或者在开发周期中的定期计划点进行代码审查。更正式的评论)。

此处的主要区别在于，小型团队全部与减少流程有关，而大型团队全部与控制通信开销有关。但是不要将小团队的动态视为不专业。小型团队比大型团队享有巨大的生产力优势。 Lawrence Putnam对此进行了一些有趣的研究，我们可以从Steve McConnell的Software Estimation：Demystifying the Black Art中找到引用(请参阅第229页)。他发现，对于中等规模的项目(约50,000行代码)，平均规模为5-7人的团队将比平均规模为15-20的团队在更少的日历时间内完成工作。我敢打赌，小型团队的代码更加协调一致，因此他们可能会完成更多的工作。

请记住，这些是普通球队。请注意，找到5个杰出人物要比找到20个杰出人物容易。因此，创建出色的小型团队比出色的大型团队要容易。鉴于有记录的个人生产率差异，我敢打赌，一个由5人组成的出色团队将比平均100人的团队拥有更高的吞吐量。而且他们在小型项目上的周转时间会更快。即使我们每人付给他们四倍的钱，那仍然是费用的1/5！