在杰夫(Jeff)关于经常入住的文章之后，一些评论者忍不住喷出"欢迎来到明显的土地！"。一种评论。这是可以理解的，在大多数情况下，很明显，在完成某些操作之后立即进行检入才是进行下一步操作的方法。

但是，那些强制执行强制性代码审查政策的地方呢？每隔30分钟要求同事进行一次复审是相当大的生产力杀手。

我会对解决方案感兴趣，或者至少对可能的折衷方案感兴趣，这将使我们在不降低团队生产力的情况下做到这两者。

解决方案

回答

如果配对程序怎么样？那么理论就是不需要同行评审。结对编程是同行评议

回答

我不知道问题有解决方案。对我来说，听起来情况属于敏捷运行的amok营地。如果我们什至在没有人看管情况下甚至无法检入(例如)空检查来修复崩溃时，听起来生产力已经受到损害。

回答

是完全没有代码，还是未经审查的主干中没有代码？我认为使用分支(希望我们不使用VSS！)可能会起作用：即仅中继更改需要同行审查。

回答

那真是愚蠢。即使我们需要代码检查也不意味着它不能被检入。这就是源代码控制的目的！尤其是如果审核受到瓶颈的影响，批处理是唯一的方法。

回答

取决于我们使用的分支策略。如果存储库正在进行发行分支，那么中继就意味着不稳定，但是策略可能源于过去的一些非常糟糕的经验。如果要进行功能分支，则可以有一条规则，规定没有对等审查，不得合并回主干。此时，与同事进行审核应该非常有效，并且应该消除瓶颈。

但是，改变分支策略绝非易事。好问题...

回答

在大多数情况下，源代码控制中的内容并不是即将发布给客户的内容。因此，我将在签入完整功能后执行reviewS，从而允许我们稍后根据需要进行编辑和/或者回滚。

回答

并非每个源代码控制系统都可以这样做，但是在处理大型项目时，我已经使用了以下过程：

• 每个开发人员都有自己的流。
• 在检查代码后，开发人员将完整的功能从其流传递到父集成流。
• 开发人员经常从集成流中更新其流。

使用开发人员流意味着开发人员可以保持可见状态，并可以在系统中备份其工作。与其他人进行协作相对比较容易，他们可以只签出信息流。通过为每个功能/缺陷创建一个新的开发人员分支，我们可以相当容易地隔离更改，例如我们需要停止使用新功能来修复紧急错误。

回答

我公司遵循部门之间不同的流程。其中一个(我最近离开)采用了结对编程，并且在签入注释中指出该代码已"成对审查"。但是，正在开发的产品已经有些成熟，并且开发过程可以忍受生产率降低。

我目前工作的部门遵循提早入住，经常入住的模式。我们正在开发具有相对较少工程师的新产品。我们每个人都通过电子邮件通知监视登机手续，并临时检查有趣的部分。不过，我目前的团队经验丰富，而且由于该项目的工程师素质，我认为我们可以不经过正式审查就可以脱身。

为了回答问题，如先前的海报所建议的那样，配对编程可能是最好的折衷方案。就个人而言，我宁愿组建一个好的团队，并让他们尽快签入代码。 (我认为，"在没有审查的情况下仓库中没有代码"是管理人员试图在不雇用质量工程师的情况下提高质量的尝试。不过，请花一点心思；我对现任雇主感到不满。 )

回答

我更喜欢保持稳定的主干和分支以进行发布，在生产后重新合并到主干中。标签用于指示代码准备情况，并且可以与代码审查策略配对。发布到SIT / UAT会获得自己的特殊标签。

在团队中，我目前只是其中的一部分，因此我们中只有3人在写作，因此同行评议是持续不断的，而且还很有趣，具有教育意义和诚实。我不是一个对我编写的代码产生感情依附的人，所以我喜欢一个不错的评论。在短时间内，我从中学到了很多东西。话虽如此，它们不是必需的。它们是有机地发生的。

如果需要同行评审，则没有理由暂停签到。只需制作一个标签来表明已进行了审核，并且一旦审核通过，则使审核员有责任将该标签应用于代码。

回答

我们在故事级别(此处为敏捷商店)进行代码审查，因此一旦我们完成了与故事相关的任务，就需要进行代码审查，然后签入。

回答

一些版本控制系统使此操作变得容易(那些具有分散策略的系统)。我已经尝试过使用一些作为公司Subversion服务器的本地中间层。

我已经使用svk维护了一个我可以经常提交的本地Subversion存储库，然后将更改(单独或者作为单个合并提交)推送到父存储库。

svk mirror
svk pull
svk push

这工作得很好，但是在svk上的开发似乎是零星的。

我已经开始尝试使用git做同样的事情。我已经做好了本地克隆的准备，但是还没有足够勇气尝试将本地提交推回去。我敢肯定这是有可能的。

git svn clone
git svn fetch
git svn dcommit

有了这个私有的本地存储库，我们可以提交所有我们喜欢的内容，然后将更改捆绑或者挑选以推送到主存储库。 (或者创建一个可以进行同行评审的补丁。)

也许两全其美？这些替代的修订控制工具不太可能在工作中获得成功，但是它们对于本地提交或者在无法访问工作存储库(我处于离线状态，旅行中等)时能够提交确实很有用。与父存储库同步。

回答

有很多好的答案。大多数人倾向于为每个需要提议审核才能合并到主干中的开发人员建议一个功能分支。但是，这将源代码控制简化为一种备份技术，而不是使某些程序员几乎在编写代码后就可以轻松共享它们的代码。

如flubba所述，最佳解决方案可能需要将分支策略更改为最适合团队的策略，但是我深感我们公司的惯性如此之强，这将需要我花费很多影响力，可能没有成功。

我会尽力的

回答

尝试总结答案，可以：

• 经常检查
• 查看所有更改
• 将所有审阅的代码合并回主干(请参见此示例)

优点：SVC中性

玉米：
在某些SVC实现中，合并可能会很痛苦(Linus Torwald的观点很好的概述)
个人分支应与中继更改同步

• 使用SVC的特定方法：
• 经常签到本地仓库
• 向公众公开(供审查)功能完整的变更集
• 将审阅的更改合并到远程存储库

优点：即使在离线状态下，SVC的优势也很好。

玉米：学习曲线很大，如果不日常使用的话，很容易忘记一些命令行内容。

• 具有适当"标签"功能的集中式SVC，请参见此讨论和概述-可能需要澄清

顺便说一句，我们不应该一直考虑做汇总答案吗？
tnx。

回答

@Coincoin：我不同意各个分支机构将源代码控制权简化为一种备份技术。我确实认为备份是使用源代码管理的原因之一，但是源代码控制在单个分支中有更多价值：

• 我可以采取一些小步骤，并在进行过程中仔细记录下来，即使它们还没有准备就绪。
• 了解我们如何到达这里是可能的，尤其是当步伐很小时。
• 查看共享分支中的更改，我们可以看到较大的步骤，然后向下钻取到单个分支以了解到达那里的较小步骤。

但是，"如果未提交，则不存在"的规则仍然适用，并且更为普遍："如果未提交/合并到共享分支，则不存在"。

我同意那些说经常签入是一个很好的做法的人，结对编程是消除代码审查延迟的解决方案。