在提交代码之前或之后进行检查，哪个更好？

传统上，我们在提交之前进行代码审查，而今天我和我的同事争论，后者喜欢在提交之后进行代码审查。

首先，这是一些背景

1. 我们有一些经验丰富的开发人员，我们也有几乎零编程经验的新员工。
2. 我们希望执行快速且简短的迭代以发布我们的产品。
3. 所有团队成员都位于同一地点。

我学过的提交前代码审查的优势：

1. 指导新员工
2. 在开发周期的早期尝试防止错误，故障，不良设计
3. 向他人学习
4. 有人退出时的知识备份

但是我也有一些不好的经历：

1. 效率低下，有些更改可能需要几天的时间才能进行审核
2. 速度和质量很难兼顾，特别是对于新手
3. 一位团队成员感到不信任

至于提交后的审查，我对此一无所知，但我最担心的是由于缺乏审查而失去控制的风险。有什么意见吗？

更新：

1. 我们正在将Perforce用于VCS
2. 我们在相同的分支（trunk或bug修复分支）中进行编码和提交
3. 为了提高效率，我们尝试将代码分成小的更改。我们还尝试了一些实时对话框审查，但并不是每个人都遵循规则。但是，这是另一个问题。

就像Simon Whitehead在评论中提到的那样，这取决于您的分支策略。

如果开发人员有自己的私有分支进行开发（无论如何，我还是建议在大多数情况下使用），然后在与主干或主存储库合并之前执行代码检查。这将使开发人员可以在开发/测试周期中自由选择所需的频率，但是任何时候只要代码进入包含已交付代码的分支中，它都会被检查。

通常，您对代码审查的不良经历听起来更像是具有解决方案的审查过程中的问题。通过以较小的单个块查看代码，可以确保它不会花费太长时间。一个很好的数字是，一个小时内可以检查150行代码，但是对于不熟悉编程语言，正在开发的系统或系统关键性的人员（对于安全性至关重要的人，则需要更多时间），速度会较慢-此信息可能对提高效率和确定谁参与代码审查很有用。

有一种口头禅，似乎没有人引用过：经常检查一下：

长期工作的开发人员（很长一段时间（平均一天以上））都没有将任何内容检查到源代码控制中，这使他们准备面对一些严重的集成难题。达蒙·普尔（ Damon Poole）同意：

开发人员经常推迟签入。他们推迟签入是因为他们不想过早影响其他人，也不想因破坏构建而受到指责。但这会导致其他问题，例如失去工作或无法返回到以前的版本。

我的经验法则是“经常签入，并且经常签入”，但请注意，您可以使用私有版本控制。如果签入对其他用户是立即可见的，则存在引入未成熟更改和/或破坏构建的风险。

我宁愿定期检查一些小片段，也不愿长时间不知道我的同事在写什么。就我而言，如果未将代码检入源代码管理中，则该代码不存在。我认为这是“ 不要走黑暗”的另一种形式; 该代码直到它以某种形式存在于存储库中之前是不可见的。

...如果您学会提早入住并经常入住，那么您将有充足的时间进行反馈，整合和审查...

我曾在多家采用不同方法的公司工作。只要不阻止编译，就允许它。如果您根本不签入任何错误，另一个人会感到恐惧。前者是更可取的。您应该在一种环境中进行开发，该环境将允许您与其他人在仍在进行中的事情上进行协作，并且所有这些都将在以后进行测试。

还有Jeff Atwood的声明：不要害怕破坏事情：

作为软件开发人员，最直接的改进方法就是更改代码时绝对不用担心。害怕代码破损的开发人员是永远不会成为专业人士的开发人员。

我还要补充一点，对于同行评审，如果有人希望您更改某些内容，那么在源代码中保留原始版本的历史记录是非常有价值的学习工具。

我最近开始在我参与的项目中进行提交前的审查，我必须说，我对它毫无问题地感到惊讶。

我看到的提交后评论的最大缺点是，通常这是一个单人的问题：有人对代码进行了正确性检查，但是除非有严重错误，否则通常不会涉及作者。小问题，建议或提示通常根本不会传达给作者。

这也改变了代码审查的感知结果：它被视为只会产生额外的工作，而不是每个人（代码的审查者和代码作者）每次都可以学习新事物的东西。

提交前的代码审查似乎很自然，我从没想到可以在提交后有意进行审查。从持续集成的角度来看，您想要在代码完成后提交代码，而不是在工作正常但可能写得不好的状态下提交，对吗？

也许是因为我们一直在团队中完成的方式是由原始开发人员发起的实时对话，而不是异步的，基于控制的，基于文档的审阅。

如今，大多数存储库都支持两阶段提交或架子集（专用分支，提取请求，补丁提交或任何您想调用的架子），这将使您能够在将其放入主线之前检查/检查工作。我想说，利用这些工具可以使您始终进行提交前的审查。

另外，您可以考虑使用配对编码（带有高级配对的初级配对）作为提供内置代码检查的另一种方法。将其视为对装配线的质量检查，而不是在汽车滚下之后进行。

两者都做：

• 预提交-当它非常重要时（例如，非常可重用的代码段或主要的设计决策），请进行此类检查
• 提交后-当您想对可能需要改进的代码发表意见时，请进行此类检查

应该对受配置控制的源文件进行任何正式检查，并且检查记录应清楚说明文件的修订。

这样可以避免任何“您没有最新文件”类型的参数，并确保每个人都在检查源代码的同一副本。

这也意味着，如果需要进行任何审核后更正，则可以使用该事实对历史记录进行注释。

对于代码审查本身，我的表决是在提交期间进行的。

像Gerrit或三叶草这样的系统（我认为）可以进行更改，然后让审阅者将其提交给源代码管理（如git）（如果好的话）。那是两全其美。

如果这不切实际，我认为提交后是最好的折衷方案。如果设计是好的，那么只有大多数初级开发人员才应该拥有足够糟糕的东西，而您却不希望他们做出任何承诺。（对它们进行提交前审查）。

这就导致了设计审查-尽管您可以在代码审查时（或在客户部署时就此事）进行设计审查，但应在实际编写代码之前比之前更早地发现设计问题。

通过同行评审，失去控制的风险极小。一直以来，两个人都知道相同的代码。它们必须偶尔切换，因此必须时刻保持专心以跟踪代码。

拥有熟练的开发人员和新手一起工作是很有意义的。乍一看，这似乎效率不高，但事实并非如此。实际上，错误更少，并且修复这些错误所需的时间更少。此外，新手将学得更快。

为防止不良设计，应在编码之前完成此操作。如果有任何重大更改/改进/新设计，应在编码开始之前进行审查。完全开发设计后，就没什么要做的了。查看代码会更容易，并且会花费更少的时间。

我同意，仅在代码是由经验丰富的开发人员（已证明自己的技能）生产后，才在提交代码之前先对其进行审核。但是，如果有新手，则应在提交代码之前对代码进行审阅：审阅者应坐在开发人员旁边，并解释他们所做的每项更改或改进。

评论可从提交前和提交后受益。

审前提交

• 使审阅者有信心他们正在审阅作者的最新修订。
• 帮助确保每个人都审查相同的代码。
• 一旦完成对审阅项目的修订，就可以作比较参考。

审核期间无运行承诺

我使用过Atlassian工具，并且在审查期间看到正在运行的提交。这会使审阅者感到困惑，因此我建议不要这样做。

审核后修订

审阅者以口头或书面形式完成反馈后，主持人应确保作者进行了要求的更改。有时，审稿人或作者可能不同意是否将审阅项目指定为过失，建议或调查。为了解决分歧并确保正确地调查项，审核小组依靠主持人的判断。

我在大约100次代码检查中的经验是，当检查者可以引用明确的编码标准时，并且对于大多数逻辑和其他编程错误，检查结果通常是明确的。有时，人们会争论关于挑剔的问题，或者风格的观点会退化为争论。但是，赋予主持人决策权可以避免僵局。

审查后提交

• 给主持人和其他审阅者一个数据点，以与审阅前提交进行比较。
• 提供度量标准，以判断缺陷消除和代码改进时审查的价值和成功程度。

这取决于您的团队组成。对于一个经验丰富的团队来说，该团队擅长小型，频繁的提交，然后提交后进行审核，只是对代码有第二眼即可。对于较大，更复杂的提交和/或经验不足的开发人员，则在提交问题之前先进行提交审查以解决问题似乎更为审慎。

遵循这些原则，具有良好的CI流程和/或门控的检入可以减少提交之前（对于许多这样的提交而言）提交审核的需求。

我和我的同事最近对此主题进行了一些科学研究，因此尽管这是一个相当老的问题，但我想补充一些见解。我们建立了一个敏捷看板开发流程/团队的仿真模型，并针对大量不同情况（不同数量的团队成员，不同的技能水平，...）比较了提交前和提交后审查。我们在经过3年（模拟的）开发时间后查看了结果，并寻找了效率（完成的故事点），质量（客户发现的错误）和周期时间（从开始到交付用户故事的时间）方面的差异。 。我们的发现如下：

• 在许多情况下，效率和质量方面的差异可以忽略不计。如果不是这样，则提交后审阅在质量方面有一些好处（其他开发人员在某种程度上充当“ beta测试人员”）。为了提高效率，提交后在小型团队中有一些好处，而提交前在大型或非技术团队中有一些好处。
• 当您遇到因审查而导致从属任务开始延迟的情况时，预提交审查会导致更长的周期时间。

从中得出以下启发式规则：

• 当您已经建立了代码审查流程时，不要费心更改，这可能不值得
  • 除非您在循环时间上遇到问题=>切换到发布
  • 或问题滑倒经常打扰您的开发人员=>切换到Pre
• 如果您还没有评论
  • 如果这些好处之一适合您，请使用预提交
    • 提交前审查允许没有提交权的外部人员为开源项目做出贡献
    • 如果基于工具，则提交前审阅会强制团队遵守某些审阅纪律，否则流程会松懈
    • 提交前审核可以轻松地阻止未经审核的更改被交付，这对于连续部署/非常短的发布周期而言非常方便
  • 如果您的团队很大并且可以在周期时间内忍受或避免问题，请使用预先提交
  • 否则（例如，熟练的小型工业团队）使用提交后
• 寻找可以为您带来两全其美的组合（我们尚未对它们进行正式研究）

完整的研究论文可以在这里找到：http : //dx.doi.org/10.1145/2904354.2904362或在我的网站上：http : //tobias-baum.de

我认为，如果在提交后完成代码同行评审，则效果最好。

我建议您调整分支策略。使用开发人员分支或功能分支有很多好处……其中最重要的一点就是促进提交后的代码审查。

诸如Crucible之类的工具将使审核过程更加流畅和自动化。您可以选择一个或多个已提交的变更集以包括在审阅中。它将显示在选定变更集中哪些文件已被触摸，并跟踪每个审阅者已经阅读的文件（显示总体完成百分比），并让审阅者轻松发表评论。

http://www.atlassian.com/software/crucible/overview

用户/功能分支的其他一些好处：

• 开发人员可以获得版本控制的好处（备份更改，从历史记录还原，差异更改），而不必担心破坏其他所有人的系统。
• 如有必要，可以撤消，重新确定优先级或搁置导致缺陷或未按时完成的更改。

对于没有经验的开发人员，定期与导师和/或结对编程进行协商是个好主意，但是我不认为这是“代码审查”。

都。（的种类。）

在提交代码之前，您应该先概述一下自己的代码。在Git中，我认为暂存区很棒。上演更改后，我git diff --cached会看到所有已上演的内容。我以此为契机，确保不检入不属于我的文件（构建工件，日志等），并确保其中没有调试代码或未注释任何重要代码出来。（如果我做的事我不知道要检查，通常我会在所有大写字母处留下评论，以便在登台时能识别出来。）

话虽如此，假设您正在主题分支上，通常应该在提交后进行对等代码审查。这是确保其他所有人都在检查正确的事物的最简单方法，如果存在重大问题，则将它们修复到您的分支或删除它们并重新开始没什么大不了的。如果您以异步方式（例如，使用Google Code或Atlassian Crucible）进行代码审查，则可以轻松切换分支并进行其他工作，而不必分别跟踪几天内正在审查的所有不同补丁/差异。

如果您不在主题分支上，应该使用。它减少了压力和麻烦，并使发布计划的压力和复杂性大大降低。

编辑：我还要补充一点，您应该在测试后进行代码审查，这是另一个赞成先提交代码的论点。您不希望您的测试小组摆弄所有程序员的数十个补丁/差异，然后仅仅因为它们在错误的位置应用了错误的补丁而提交错误。

100％的配对编程（无论您认为自己有多高级），都具有许多小的提交，并且在每次提交的基础上构建CI系统（尽可能自动进行单元，集成和功能性测试）。提交后的审查，涉及较大或冒险的更改。如果您必须进行某种封闭/预先提交的审查，那么Gerrit可以工作。

签入代码（检查预算）的好处是在完成大段代码之前立即获得反馈。

检入代码审查的缺点是，它会阻止人们在长段代码完成之前进行检入。如果发生这种情况，它将完全否定优势。

更困难的是，并非每个开发人员都一样。简单的解决方案并不适合所有程序员。简单的解决方案是：

• 强制配对编程，由于好友就在您旁边，因此可以频繁检入。这忽略了结对编程并非总是对每个人都有效。如果做得好，结对编程也可能真的很累，所以不一定要整天做。

• 开发人员分支，完成后仅在主分支中检查和检查代码。一些开发人员倾向于保密工作，一个星期后，他们提出了一些代码，由于较早发现的基本问题，这些代码可能会通过也可能不会通过。

• 每次入住时都要进行审查，以确保经常审查。一些开发人员会健忘，并且需要非常频繁地签入，这意味着其他开发人员必须每15分钟进行一次代码审查。

• 入住后一些未指定的时间进行检查。如果有最后期限，那么评论将被进一步推出。依赖于已提交但尚未审阅的代码的代码将被提交。审查将标记问题，并且这些问题将被放入待办事项列表中，以“稍后”解决。好的，我撒谎：这不是一个简单的解决方案，根本不是一个解决方案。办理入住手续后，可以在指定的时间进行检查，但它不那么简单，因为您必须确定指定的时间是什么时间

在实践中，您可以通过使其更简单，更复杂的方式来完成这项工作。您设置简单的准则，然后让每个开发团队以团队的方式弄清楚他们遵循这些准则需要做什么。此类准则的一个示例是：

• 工作要花不到一天的时间来分解。
• 如果尚未签入代码（如果有），则任务未完成。
• 如果未检查代码（如果有），则任务未完成。

这种准则的许多替代形式都是可能的。专注于您真正想要的（同行评审的代码，可观察的工作进度，问责制），让团队弄清楚他们如何才能给您他们想要的东西。

我们实际上在LedgerSMB上进行了混合。提交者提交更改，然后进行审核。非提交者将更改提交给提交者，以供审核。这往往意味着两个层次的审查。首先，您需要一位导师来审核和指导您。然后，该指导者在他或她签署该代码并进行反馈之后，第二次对代码进行审查。新提交者一开始通常会花费大量时间来审查其他人的提交。

效果很好。不过，事后审查通常比事前审查更为粗略，因此您要确保事后审查保留给已证明自己的人。但是，如果您对新成员进行两层审查，那的确意味着问题更有可能被抓住，并且进行了讨论。

提交到哪里？我创建了一个分支来做一些工作。只要有需要，我都会致力于该分支。没关系 然后在某个时候将该分支集成到开发分支中。介于两者之间的是代码审查。

在我承诺进入分支机构后，审稿人显然会进行审阅。他不在我的办公桌旁，因此在我提交我的分支之前他无法对其进行检查。他在合并之前进行了审核，并致力于开发部门。

只是根本不进行代码审查。您要么相信您的开发人员有能力编写良好的代码，要么就应该摆脱它们。逻辑错误应通过自动测试发现。错误是样式应该由皮棉和静态分析工具捕获。

让人们参与应该是自动过程的过程只是浪费。