何时进行代码审查

我们最近进入了Scrum流程，并且正在sprint中处理任务和用户故事。我们希望经常进行代码审查，以减轻他们的负担。我们正在考虑在用户故事级别上执行这些操作，但是不确定如何分支我们的代码来解决此问题。

我们使用的是VS和TFS 2010，我们由6人组成。

我们目前为功能分支，但正在努力更改为Scrum分支。

我们目前不使用架子集，如果有其他可用的技术，我们也不想真正实现。

您如何建议我们针对每个用户案例实施代码审查？

这取决于用户故事的性质。

为每个用户故事创建一个分支可能是有效的，可以看到不同故事的进度，可以根据需要传递它们，如果故事未在sprint中完成，则进度可以留在分支中进行下一个sprint 。然后，可以在使用案例分支中的用户案例的末尾执行最终审阅，如果代码符合标准，则可以将其合并。

为了以这种方式工作，需要对故事进行细化处理，以防止在冲刺结束时执行难以处理的合并任务。小型故事将允许通过sprint不断更新dev分支，而处理其他用户故事的开发者需要不断地从这些sprint中提取（基本VCM）。

这确实增加了必须经常创建和合并分支的过程开销，在某些情况下可以使用自动化脚本来解决这些问题，但是团队仍然需要非常熟悉VCS。

在sprint结束时，您将自己的dev分支合并到Integration / production等中。

我还曾在团队中工作过，每个人都在一个dev分支工作，在完成用户故事后，代码将推送到该分支进行审查和测试，如果有人推送了一些破坏了dev的东西，他们就必须加入团队。

审查代码的最有效方法是站起来，找一个人，然后请他们过来讨论您刚刚开发的代码。

除非找不到其他人可以在本地查看您的代码，否则请不要使用该工具。

您可以通过配对完全避免代码审查。

团队中的每个人都在本地吗？如果是这样，请在签入代码之前让别人过来看看。不是本地的吗？启动您最喜欢的屏幕共享程序，然后呼叫某人。我个人经常这样做。有时我只是说“嘿，看看我做了什么！”

我更喜欢这种特殊的代码评审样式，而不是有人站起来向团队展示其代码的样式。临时审核可以为您带来许多（全部？）配对的好处，而不会造成尴尬。另外，您的“审阅者”更有可能提出问题并提出非正式的一对一设置建议。

我认为代码审查不是SCRUM的正式部分，但修订是提高质量和改善项目/团队的独立策略。

因此，您将使用SCRUM（或其他敏捷开发方法）来确保/提高PROJECT的质量并按计划进行。另外，一个好的策略是在正常的质量检查/测试任务中独立进行产品修订（而不是代码）。如果可以在您的团队/合作伙伴/客户/观众面前进行这项活动，那就更好了。

您应该使用代码（或其他特定的）修订版，主要是为了改善TEAM，并期望获得中长期的结果。这将影响您的项目，但从长远来看，这是您TEAM改进的产物。

因此，为回答您的问题，我相信您正在尝试从SCRUM推开太多，您最好仅按原样考虑修订。

在签入代码之前进行代码审查不是很明显吗？

TFS不能像GIT那样工作，因此每当您将代码签入分支或主干时，每个人都可以使用它。

这意味着检查应该在签入时进行，这样不好的更改就不会传播到每个人的工作副本中。