使用TFS搁置集的原因之一是代码审查，我不同意，但这是我当前项目中遵循的做法。我看到使用TFS搁置集的原因不是代码审查的好主意
有人可以为我提供一些指示，可以 或反对 TFS搁置集方法进行评论，这样我才能确信这种方法或者我可以提出一个案例不使用这种方法？
答案 0 :(得分：11)
我认为微软在这一方面不同意你，因为TFS 11和Visual Studio 11中的新Code Review功能是围绕搁置集构建的。真正的问题可能更多地围绕团队的运作方式以及任务在整个产品中的分配方式。
如果任务已被拆分，使得他们几乎没有依赖关系，并且在同一区域工作的人员紧密合作，那么您在合并和签到时就不会遇到任何问题。如果您的任务需要花费更多时间，那么请定期从开发分支中获取最新版本，以便您始终保持最新状态。
如果您发现审稿人太慢并且搁置集正在排队，所有人都在等待审核，那么这就是其他真正问题可能发生的地方。任务完成后，应尽快进行审核，而不是等待审核。如果评论的时间超过24小时，那么这可能会成为一个真正的问题。您可以通过由其他人进行同行评审或在团队中获得更多评论者来缓解这种情况。
如果所有其他方法都失败了，您可以进行事后审核（查看更改集而不是书架），TFS 11和Visual Studio 11也支持此方案。
我个人的偏好是信任我的团队中的开发人员，因此我们主要做的是签入后的评论。如果我们有新的或非常初级的成员，那么我将确保有更高级的开发人员可以进行首次预签入审核。
另见：
答案 1 :(得分：6)
Shelveset没有变更集所具有的自然顺序。这个可以 导致很多合并冲突。
我在这里看不到你的观点，对你来说什么是“自然的顺序”？当您开始在团队中工作时，变更集的年表不遵循给定的顺序。
如果开发人员在审核之前无法签入代码，请填写 依赖审稿人以及审稿人是否进行审核 在很短的时间内，这些搁架会干扰其他搁架 任务。
同样，你和“常规任务开发”的情况相同，这不是因为你在任务B之前启动任务A，你将在B之前签入任务A（除非B依赖于A，但这不是这一点）。将审核视为任务开发工作流程的最后一步。对审阅者的依赖确实使事情变得复杂一些，但这是为了拥有稳定的构建并使代码符合公司的标准。
与其他开发者的合作变得很痛苦，因为现在你需要通过 搁置而不是签入代码，这可能再次导致合并 未来的冲突。
你知道比搁置更容易的东西吗？您更喜欢在zip文件中发送包含修改后代码的电子邮件吗？当您不想影响参考时，Shelvesets是开发人员之间共享代码的最简单方法。在这里，我再也看不到您提到的合并冲突问题。
以下是一些建议：
当有人回到另一个开发区的搁架时，说Dev A创建了一个搁架，Dev B想要查看它，确保Dev B有一个单独的干净且专用的工作空间来取消搁置。您不希望在常规“开发”工作区中取消搁置。用于代码审查的专用工作区可以缓解您提到的合并冲突问题。
理论上，在集成到目标分支之前，应该检查所有内容。话虽这么说，实际上这样做更难，所以如果你的团队没有这种过程的习惯，那么就不要做一些完美的事情。熟悉他正在处理的应用程序的高级开发人员可以在审核之前获得授权登记。这都是权衡问题，在这种情况下，您可以获得灵活性和更流畅的开发体验，但您的参考可能会受到质量和稳定性的影响。这里没有真正的赢家，这是你根据对你重要的选择。
请勿使用分支进行代码审核。
我同意通过shelveset进行代码审查的经验在VS / TFS中有些不完整，但对替代方案来说更好。微软意识到他们可以在这方面做得更好，它转化为VS11 / TFS11的改进。在下一个版本中，您拥有真正的代码审查体验，仍然基于shelveset，但在actor之间有更完整的通信系统。这种改进是在“我的工作”体验中进行的，现在事情变得更加顺畅了。试试tfspreview.com和VS11 beta或阅读一些博客文章（Brian Harry）以获取更多信息。这是您感兴趣的a link。
答案 2 :(得分：2)
这不是搁置的问题所在。如果你等待同行审查你的代码，那么代码的存储方式不会产生太大的影响。也就是说，搁架可以安全地存放在您的计算机上，位于审阅者可以访问的位置，所以我认为它是一个很好的解决方案。另一种方法是办理登机手续，绕过变更集，如果没有通过集合或传递拉链，则还原？两者都有明显的缺点。
那么，在办理登机手续之前，您是否应该进行必要的代码审查才是真正的问题？