在源代码控制存储库中进行“评审”源代码的最佳实践是什么？

Question

在源代码控制存储库中管理已评审的源代码的最佳方法是什么？在签入之前，源代码应该经过评审过程，还是应该在代码提交之后进行代码评审？如果在代码签入到存储库之后才进行评审，那么应该如何跟踪呢？

Answer 1

我在多个团队中使用的一种技术是：

• 开发人员可以在自己的分支或本地回购系统上集成源代码，而无需审核。
• 开发人员可以与主干/主站集成而不需要检查。
• 在将代码从主干/母版集成到发布候选分支之前，必须对代码进行检查，并处理评审注释。

寻求评审是代码作者的责任，而发布分支维护人员的责任是确保只合并经过评审的代码。

有些工具支持代码评审，但我从未使用过它们。跟踪谁做了任何合并的审查可以在回购内完成。我使用了svn属性和附加到提交的绝对任务，以显示谁审查了什么。

Answer 2

我从来没有将代码分开，以便由commited/non标准进行评审--我遇到的唯一标准是单元测试和集成测试是绿色的。

至于跟踪，我建议更新您最喜欢的问题跟踪器中的流。例如:而不是：

• 产品所有者->分析师-> Developer -> QA ->发布工程师

您可能需要再介绍一个阶段(回顾)：

• 产品所有者->分析师-> Developer ->审查员-> QA ->发布工程师

因此，对于每一张处于已实现状态的票证，您都可以指定一个审阅者，并且只有经过审查的票证才能提前到QA。

Answer 3

我只有一次代码评审的经验，所以我不能说它有多好。

我和一小群(10-15)的程序员一起工作，我们使用的是VS。我们被要求每天提交一次代码，在每个提交代码被小组中的其他人(希望也是参与项目的人)评审之前。在提交期间，该人员的姓名也包含在字段中。