仅使用代码注释的代码审查是一个好主意吗？

前提条件

• 团队使用DVCS
• IDE支持注释解析（例如TODO等）
• 诸如CodeCollaborator之类的工具预算昂贵
• 诸如gerrit之类​​的工具过于复杂，无法安装或无法使用

工作流程

• 作者在中央回购功能分支上的某个位置发布
• 审阅者获取它并开始审阅

• 如果有任何问题/评论，请创建带有特殊标签的评论，例如“ REV”。此类标签不得在生产代码中-仅在审核阶段：

  $somevar = 123;
  // REV Why do echo this here?
  echo $somevar;
  

• 当审阅者完成评论后，它只会发送愚蠢的消息“ comments”并向后推送

• 作者将功能分支拉回并以类似方式回答评论或改进代码并将其推回
• 当“ REV”评论消失时，我们可以认为，该评论已成功完成。
• 作者以交互方式为功能分支重新设置基础，挤压功能分支以删除那些“注释”提交，现在可以合并功能以开发或进行任何成功的内部检查后通常可以采取的操作

IDE支持

我知道，自定义注释标签可以在Eclipse和Netbeans中使用。当然，它也应该属于blablaStorm家族。

问题

1. 您认为这种方法可行吗？
2. 你知道类似的东西吗？
3. 有什么可以改进的吗？

这个想法实际上是非常好的。与常见的工作流程相反，您可以直接在代码中保存审阅，因此从技术上讲，您不需要文本编辑器即可使用此工作流程。IDE中的支持也很好，尤其是能够在底部显示评论列表。

仍然有一些缺点：

• 它对于很小的团队来说效果很好，但是较大的团队将需要跟踪所审查的内容，时间，人员和结果。尽管您实际上具有这种跟踪功能（版本控制可以让您了解所有内容），但使用和搜索都极为困难，并且通常需要通过修订版进行手动或半手动的搜索。

• 我认为审稿人没有从审稿人那里得到足够的反馈来知道审稿要点是如何实际应用的。

  想象以下情况。爱丽丝第一次审查埃里克（Eric）的代码。她注意到，年轻的开发人员Eric使用的语法并不是实际使用的编程语言中最具描述性的语法。

  Alice建议使用另一种语法，然后将代码提交回Eric。他使用他认为正确理解的替代语法重写了代码，并删除了相应的// BLA注释。

  下周，她收到了第二次审核的代码。为了看看Eric是如何解决的，她是否能够真正记得她在第一次评论时所说的话？

  在更正式的审查过程中，爱丽丝可以立即看到她说的话，并查看相关代码的差异，以发现埃里克误解了她告诉他的语法。

• 人还是人。我非常确定，其中一些注释将最终出现在生产代码中，而某些注释将在完全过时的同时保留为垃圾。

  当然，任何其他评论都存在相同的问题。例如，生产中有许多TODO注释（包括最有用的注释：“ TODO：注释下面的代码。”），并且有许多注释在相应的代码更新时未更新。

  例如，代码的原始作者或审阅者可能会离开，而新的开发人员将不会理解审阅的内容，因此评论将永远保留，以至于某人过于勇敢以至于无法消除它或真正理解了什么。它说。

• 这不能代替面对面的审查（但是，同样的问题也适用于未进行面对面的任何其他更正式的审查）。

  特别是，如果原始审稿需要说明，审稿人和被审稿人将开始某种讨论。不仅您会发现自己带有大量BLA注释，而且这些讨论还会污染版本控制的日志。

• 您可能还会遇到语法方面的小问题（TODO注释也存在此问题）。例如，如果长的“ // BLA”注释在多行中产生，而有人决定以这种方式编写该怎么办：

  // BLA This is a very long comment which is way beyond 80 characters, so it actually
  // fills more then one line. Since the next lines start with slashes, but not "BLA"
  // keyword, the IDE may not be able to show those lines, and display only the first one.
  

• 最后，作为一个简短而非常个人化的注释：请勿选择“ BLA”作为关键字。听起来很丑。;）

我将用一个随附的文档补充代码中的注释。这将总结调查结果，并在删除评论后继续存在。这样做的好处是：

• 紧凑。如果此人通常无法检查传入的指针是否为null（或者您使用的语言存在其他一些常见的初学者错误），那么审阅者可以留下数十条这样的REV注释，并且在文档中可以说“我找到了37个未先检查指针的地方”，但未列出所有地方
• 值得称赞的地方。像这样的注释REV this is a nice design看起来有些奇怪，但是我的代码审阅通常包括批准和更正。
• 互动性。您的样本评论是“您为什么这样做？” 这是非常典型的 仅评论方法不支持对话。该人员可以更改其代码并删除评论，或删除评论。但是“你为什么这样做？” 和“请更改此设置，这是错误的”不是同一回事。
• 保持记录。稍后的审阅者可以检查代码是否实际上已更改，或者注释是否刚刚删除。他们还可以检查评论是否已经“接受”，并且开发人员在以后的审查中不再犯相同的错误。

我还将使用一个工作项来进行审阅并响应审阅，并将签入与其相关联。这样可以很容易地在旧的变更集中找到注释，并查看在另一个变更集中如何处理每个注释。

其他人则谈到了这种方法的局限性。您提到很难安装gerrit之类​​的工具-我建议您看一下phabricator（http://www.phabricator.com）。这是Facebook使用多年的代码审查系统，并且最近已开源。它安装起来并不难，拥有出色的工作流程，并且可以解决其他注释中提到的所有问题。