我正在尝试为我的团队找到一个很好的代码评审工作流程。大多数类似于SO的问题都是围绕使用搁置的更改进行审查，但我很好奇这是如何适用于大型团队的人员的。使用TFS的大型ASP.NET MVC团队的代码评论
我们通常有2-3个人在讲故事（UI人员，Domain/Repository人员，有时候DB人员）。我推荐了架子的想法，但我们都关心如何管理多人使用同一功能。那么你怎么能在多个程序员之间共享一个架子呢？我们担心它会很笨重，我们可能很容易在这个工作流程中产生意想不到的后果。
当然，移动到每个功能的搁板上可以避免每个功能有10个左右的checkins（因为开发人员需要共享代码），使得在代码检查时看到差异是痛苦的。
有没有其他人能够成功地处理这个问题？除了TFS架子（最好是开源）之外，有没有人发现有用的工具？
团队是否分布？如果没有，那么也许只是尝试一些XP技术，如配对编程（即使不是所有的时间），并让开发人员在功能上一起工作。当发现问题时，连续沟通通常比指定特定事件（如代码评论）更好。
，即使团队分发了，那里有一些非常好的工具用于远程对编程 – 2010-10-15 12:04:36
与TFS一起使用搁架的主要注意事项是，您不能在不同分支上的搁架之间进行差异。您只能对由shelveset创建的分支进行区分。
此外，通过其他人对shelveset所做更改来更新当前更改的支持并不好。当您将搁架组拉到本地机器上时，默认操作是覆盖本地内容，而不是合并。我不确定在那里是否支持合并。
因此，从服务器进行更新时，多人对同一个shelveset进行更改可能会很尴尬，并且有可能覆盖本地工作。
对于TFS，您可能会更好地为每个迷你团队使用分支，因为您可以通过这种方式在各个方向获得完全合并支持。
一些其他版本控制系统（GIT，可能是StarTeam）具有“个人分支”的概念。这就像TFS的shelveset，但它的行为更像是一个真正的分支，因为你可以将它合并到TFS中，不像TFS shelveset。
附注：不要害怕多个更小的签到。您可以一次区分签入范围，以将多个签入合并为一个差异。作为个人风格的问题，我更喜欢经常检查小编辑，而不是坐在怪物修订版上几天或几周（或几个月！）。大的修改需要更长的时间来审查，产生更大的风险，即某些事情会被忽略或中断，导致更高的可能性，因此您将不得不手动解决合并冲突，并且会失去1个错误1：1的跟踪原子性。
保留一个大签入的修订有时被称为“便秘”工作流程。 ;>
一些后续问题;你同时运行多少个故事，整个团队有多大，你可以做更小的迭代（即使你没有发布）？
还不知道答案我会说;
如果故事的复杂性不需要不同的分支，那么只需在迭代结束时对所有更改进行完整的代码审查，如何？这样你不仅可以看到所有的变化，而且可以看到它们如何一起工作。如果人们无法接受他们在审查过程中所做的更改，则您始终可以找到变更集（但在此时您确实遇到了更大的团队问题）。根据你的团队的规模，这可能不实际。
最后一个想法;良好的测试覆盖率和持续集成是救命稻草。
我得到了TFS和ReviewBoard的工作。
http://blogs.pinet.ca/tim/2010/08/24/code-review-goodness-with-reviewboard/
添
只要有一个人取消搁置另一个补充搁置。 – 2010-03-12 19:41:28
为什么不用功能分支去分享人们之间的变化？这会导致分支太多吗？ – Ryan 2010-03-12 20:23:03
@Ryan分支可能会难以维护。我们通常每个迭代有一个月的迭代和7-10个特征。 @John如果从架子上拉下来的人必须搁置另一个人才能重新找到它，那么这有多好呢？在共享代码的几次复飞之后，这会不会变得混乱？ – Parrots 2010-03-13 15:47:22