与SVN和ReviewBoard成功的代码审查策略？

Question

我已经成功地将ReviewBoard引入到我公司的编码工作流程中，而“引入”意味着已经安装并呈现它。我们也有一个普遍的协议，我们需要严格的代码审查，但是，我们不太确定我们想如何去做。

我们的主版本控制是SVN，所以我们在分支和合并方面相当有限。我已经考虑过的一些策略：

1. 从主干预先提交审查。优点包括拥有一个补丁，在版本库中没有未经审查的代码。对比度不得不保持结帐清洁或者做几个结帐的穷人分支
2. 从干线发送后的评论。审查委员会可以很好地工作，但它不会阻止人们犯下脏代码，也可以让他们忽略审查请求。
3. 来自功能分支的提交后审查。优点是显而易见的，因为一个特性可以独立工作，但是在创建基于服务器的分支方面存在巨大的痛苦，并且在保持不同分支同步方面也是一个巨大的痛苦。另请参阅第2项。

我希望尽可能无痛，因此有几种可能的工作流程自动添加，例如机器人提交至少获得X的代码“运送它！”。投票和让审查委员会“跟随”具有提交钩子的功能分支。不过，我不确定哪个代码审查工作流程可能对我们约8个编码人员的团队来说是最好的。我们将无法更改修订控制系统，即git-svn和SVK不可能出现问题（而后者无论如何都已经死掉了）。

你能从你的经验中推荐任何东西吗？

Answer 1

基地你的信任和责任，并保持它的重量轻系统：

1. 使用良好的判断：“你可以在任何时间任何检查。当你需要时请求代码审查。'如果评论为了方便快速评论而添加'评论者'以评论。
2. 评论板负责通过提交挂钩监视更改。如果他们看到他们不喜欢的东西，请与开发人员讨论。不同的成员可以查看不同部分。
3. 如果开发人员继续检查垃圾而不要求复查，请将其解雇。
4. 如果系统的某些部分异常复杂/中心/容易混乱 - 锁定这些部分并需要批准登记。
5. 每个人都可以监控签入。审查不仅仅是为了审查委员会。

我已经看到了这个工作，2个开发人员，并与100

Answer 2

你的＃2，＃3（也许如果关注的分支已经审核简称主干评论）的组合可以很好地工作。我发现预先提交的评论有点令人窒息的过程 - 最好有一个热情（由你点燃？）审查感染整个团队。

我推荐阅读SmartBear的免费书籍Best Kept Secrets of Peer Code Review，这是一个非常平凡的待遇。考虑到其作者出售商业代码审查套件。 （我不为他们工作，也不使用他们的产品，FWIW。）

这本书可以帮助你思考你的环境的两种可能的工作流程，以及如何引入工作流程，向团队解释为什么你可能希望瞄准x-loC或更少的评论，或者有一点点导游之前评论等

Answer 3

我们处于类似的位置。

你有没有配置svn来给每个提交的所有开发者发邮件？这是保持每个人诚实的良好开端。我们发送一封电子邮件，其中包含日志消息，svn diff的前200行以及trac中的全部差异链接（基本上只用于显示svn差异）。

如果开发人员认为事后需要审核变更，我们会使用ReviewBoard进行审核。

另一方面，开发人员也可以在办理登机手续前申请审查。无论他们是在功能分支还是在中继沙箱中开发更改，都没有区别。我们已经考虑调整脚本以从命令行上传审阅请求，但是这个过程非常简单，至少我们还没有这样做。

我的总体建议是引入一个手动系统并将其自动化，并且可能在预处理脚本满意后执行它。特别是对于一个小团队来说，最好是在同伴压力执法方面犯错，因为您希望尽量减少小生产力查杀流程的数量。

Answer 4

我们最近在我们的流程中引入了ReviewBoard。在我们添加ReviewBoard之前，我们已经完成了以下工作：

1. SVN通过电子邮件自动发送给所有开发人员进行每次签到。
2. ViewCV集成以允许在浏览器提交后查看差异。
3. SCM-bug脚本与SVN集成在一起，因此开发人员必须在他们的checkins中包含一个大的id。
4. Buildbot与SVN集成在每次签入后自动运行测试。

既然我们已经有了覆盖相当好与其他的东西后提交的东西，我们使用ReviewBoard作为一个pre-commit工具，只有经过我们打“功能完善”一个给定版本。

Answer 5

在大型开发中，功能分支是不可避免的。使用SVN，不可能从工作副本更新中继的功能分支。但是，您可能会频繁合并和创建新分行。

顺便说一下，R​​B知道处理预先提交评论。

Answer 6

我同意第一种观点：从树干

预提交审查因为使用的代码审查工具，确保在库中没有未查看的代码，并保持你结帐干净