何时进行代码检查

Question

我们最近转向了scrum过程，并在sprint中处理任务和用户故事。我们希望经常进行代码评审，以使它们不那么令人生畏。我们正在考虑在用户故事级别上这样做，但不确定如何将代码分支来解释这一点。

我们使用VS和TFS 2010，我们是一支6人的球队。

我们目前正在进行特性分支，但正在为scrum更改为分支。

我们目前不使用搁置集，如果有其他可用的技术，我们也不想实现。

您建议我们如何实现每个用户故事的代码评审？

Answer 1

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

为每个用户故事创建一个分支是有效的，不同故事的进度是可见的，如果需要可以传递它们，如果故事在sprint中没有完成，那么进度可以留在分支中，以便下一个sprint。然后，可以在用例分支中的用户故事结束时执行最终评审，如果代码符合标准，则合并到其中。

要想以这种方式工作，故事需要细粒度，以防止在sprint结束时无法管理的合并任务。小故事将允许通过sprint稳步更新开发分支，开发人员在处理其他用户故事时需要不断地从中提取(基本VCM)。

这确实创建了流程管理，必须不断地创建和合并分支，在某些情况下可以使用自动化脚本来解决这些问题，但是团队仍然需要对VCS非常满意。

在sprint结束时，您可以将开发分支合并到集成/生产中，等等。

我还在团队中工作过，每个人都在一个dev分支上工作，在用户故事完成后，代码会被推送到该分支进行审查和测试，如果有人推出了一些破坏dev构建的内容，他们就必须让团队成员参与进来。

Answer 2

检查代码最有效的方法是站起来，找到一个人，让他们过来讨论你刚刚开发的代码。

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

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

Answer 3

队里每个人都是本地人吗？如果是这样的话，在签入代码之前，只需要让人过来看看就行了。不是本地的？启动你最喜欢的屏幕共享程序，然后打电话给别人。我个人经常这样做。有时候我这么做只是想说“嘿，看看我做了什么！”

比起有人站起来向团队展示他们的代码，我更喜欢这种风格的临时代码评审。特别的评论可以给你很多(全部？)在没有尴尬的情况下配对的好处。另外，你的“评审员”更有可能在非正式的一对一的环境中提出问题并提出改进建议。