如何组织代码评审过程

Question

我在寻找一个轻量级的代码评审过程。有几个要求，审阅者必须能够在他/她选择的时候单独进行评审(不与签入绑定)，审阅者必须能够很容易地找到目标代码，评审必须留下一些文档来显示所审阅的内容。我知道有一些工具可用于代码审查，但我在一个非常复杂的环境中工作，引入新工具不是一种选择。

我一直在考虑的一个想法是创建一个名为REVIEW的新Visual任务列表标记，并使用它标记需要检查的代码。

就像，

// REVIEW doe_john: New method, not sure about the exception.

然后，我们将在TFS中添加一个Review工作项(我们使用CMM模板)。

我更喜欢的另一种可能性是让开发人员创建一个TFS工作项并向其添加代码链接，但我不知道这是否可行。显然，您可以向文件添加一个链接，但我希望有一个指向特定方法的链接。

PS。最初发布到StackOverflow。

Answer 1

我们过去经常进行手动代码检查(即没有特殊的工具)，这是我们发现的最好的方法。我们的开发部门没有团队基础服务器，所以我不能对此发表评论。

1. 所有工作都与具有唯一ID的bug或敏捷故事相关联。当工作被签入(或搁置，即提交而没有实际签入)时，描述将始终具有此标识符。
2. 在一个站起来或超过电子邮件，审查者将被通知错误###或故事###已经准备好接受审查。
3. 它们在文件的新版本和以前版本之间进行源代码管理，并将diff的输出复制/粘贴到word文档中。我们有一个代码审查word文档模板，它是预先设置的，有两个级别的标题:级别1-模块，级别2-文件名。它还为实际代码(8PTConsolas)定义格式样式。这一步显然是最大的痛苦，但是有了Word模板和Ctrl，Ctrl，Ctrl序列，点击就不那么多了。
4. 既然文档在word中，审阅者就可以突出显示所讨论的代码，并使用Word的审查系统添加注释。
5. 所有文档都存储在文档存储库中，并标注了相应的bug或故事编号。
6. 文档完成后，指向存储库的链接将与原始开发人员共享。然后，如果更改足够重要并且需要讨论，我们要么举行代码评审会议，要么让原始开发人员在自己的时间内进行评论。

在尝试了许多手动方法之后，我们发现这个方法的开销最少，同时允许我们实际查看每个更改。

然而，我们的工程团队刚刚推出了审查委员会，虽然我还没有那么多地使用它，但到目前为止，我很喜欢我所看到的。它具有word文档的所有灵活性，但不再复制/粘贴和手动修复格式。作为额外的奖励，它保留了所有评论的永久存档，这样你就可以追溯到几年前，如果你需要的话。此外，它还允许您做不同的差异，这是很好的时候，您想要做一个代码审查。这部分我们发现手动过程非常困难，因为您无法看到在第一次代码评审时更改了什么，相反，您最终会重做整个过程。

虽然你说你不想使用工具，但我强烈敦促你考虑审查委员会。它是开源的，完全免费的。这样你就可以为你自己和可能和你一起工作的5个人推出它了。如果你公司的其他人不想使用这个工具，他们就不用使用这个工具了。而且你也不需要担心是否会得到任何购买许可。

==更新到来自问题的评论：==

在我的团队里，我们有纽约，CT，TX，波兰和印度的人。让事情变得更有趣的是，极高比例的团队对产品或技术不太了解，所以很少有人会做大部分的评论。所以是的，高级开发人员肯定很忙。在我概述的过程中，主要审阅者将按照自己的计划独立完成代码的初始演练。但是之后，我们安排了一次会议，主要审查员通过他的评论引导编码器。会议可以有其他审查员，但他们被认为是次要的，没有义务(但不劝阻)审查每个文件或发表评论。

我同意其他人的意见，即即使你必须使用网络会议，也可以实时举行最后一次会议，这对知识转移和帮助新来的人理解代码都有好处，这样他们就可以开始生产那些让你的高级开发人员更加忙碌的事情。但是，这也取决于评论的数量和类型，有时(很少)的评论太小，以至于会议被跳过了。

当你说推出新工具很难的时候，我也能和你联系起来。我在一家非常大的公司工作，通常有这么多人参与，即使在没有批准任何收购的事实之外，也有如此多的利益/议程，以至于从来没有达成一致意见。审查委员会的好处是，您可以跳过所有这些，只需开始与您的小团队一起使用，如果有必要(如果真的是这样的话)，您可以在您自己的开发机器上托管web服务。

Answer 2

使用一个工具-有很多好的代码审查工具。有了它，这个过程相当简单：

• 使用要查看的源文件创建项目
• 添加要查看代码的人员
• 为评审分配时间
• 在时间流逝时检查评审结果。

我个人使用了码射手，但也有许多其他代码审查工具。