我想更好地了解成功进行代码审查的有效模式和无效模式。

• 正式代码审查和非正式代码审查应该有区别吗？
• 人们需要什么级别的《代码审查》文档？
• 在没有代码作者参与的情况下，代码审查会同样有用吗？

解决方案

首先看一下Fagan检查的概念。

这种方法确实可以提高审阅代码的质量，并且实际上可以提高审阅本身的质量！

并始终记住批评代码而不是编码器。

使用Eclipse Jupiter插件并遵循其自动化的过程对我们来说非常有效。它虽然不太具侵入性或者官僚作风，但仍然确实有助于发现错误和设计问题。

我曾经做过的最好的代码审查涉及Smartbear的一个名为Code Collaborator的工具。
作者将代码上传到服务器。审阅者和观察者可以看到新代码和旧代码之间的差异，并可以对新代码进行注释。
以下是最佳做法：

• 作者对编写的代码发表了评论，以向审稿人提供从何入手的线索。
• 审核者发表评论并添加需要接受的缺陷才能修复。只有重要的事情才应标记为缺陷。不是错别字或者我们知道开发人员会在提交前解决的问题。
• 让新开发者作为观察员参与。这是使他们熟悉该项目的良好培训。
• 以观察员或者审阅者的身份让代码专家参与其中。

反模式：

• 使用代码审查工具作为设计审查工具。不适合这样。仅审阅已同意设计的代码。
• 涉及过多的审阅者和观察员
• 让评论在系统中徘徊超过两天。

我认为对良好的代码审查至关重要的模式是，让程序员有时间和动力来真正地阅读和理解作为审查者的代码。仅给代码一个粗略外观并指出一些代码样式更改的审阅者并没有真正对流程做出贡献。

• 定期且频繁地安排审查或者检查。重新检查/检查整个模块，并检查增量和周围的代码以进行维护。积压待审核的材料使整个过程变得令人生畏。
• 从最低级到最高级，每个人的代码都将得到审查，并且任何人都可以发表评论，而不必担心受到指责。
• 不要只是查看/检查代码；查看测试(尤其是TDD测试)和测试结果。通过发现我们以为我们所测试的并不是真正的被测试对象，或者当我们以为我们使用不同的类时，我们无意中使用了同一个等效类的测试数据，从而发现了一些有趣的错误和测试遗漏数据的。

我认为应该没有正式和非正式的时间，而是有不同类型的时间来进行代码审查。如果有一个尽快解决的错误，并且代码更改仅是几行代码，这可能仍会得到审查，但可能与采用新的ERP或者CRM系统形成对比的方式不同。同样，在某些情况下，可能会留出几个小时来审核某些代码，而在另一些情况下，则需要不到5分钟的时间。

该文档可以采用几种形式。可能只是一封电子邮件，说乔审核了鲍勃的工作，并且已批准将其进入下一阶段进行发布。或者，在升级代码之前，可能要写几页关于更改内容的注释，以便使用某些设计模式并将代码从其初始的快速脏表单中清除。

至于最后一个问题，我认为答案有时是。如果我们有一些代码想要就如何优化代码获得其他意见，那么不让作者参与可能会有助于我们获得构想，然后让作者进行更改或者说明更改为何不能改善代码的合理性。代码，例如如果有人想加入冒泡排序算法，则可能会因为其他更有效的排序算法(如快速排序，合并排序和堆排序)而被拒绝。

编辑添加了一些我认为有用的模式：
对于错误修复代码检查，我最喜欢的模式如下：
1)在测试/分阶段环境中显示错误，以便我可以找出问题所在。
2)向我展示代码的更改位置，并简要说明了为何以这种方式更改了代码。
3)告诉我代码已在本地计算机上固定。

相反，如果一个人用十二种方法来实现一种API，那么最好有一些文档来总结实现中所使用的内容以及做出某些选择的原因，例如使用了哪种列表实现，例如数组，哈希表，链接列表，泛型列表，堆栈，队列等。

我的公司Smart Bear是Code Collaborator(代码协作者)(David Segonds提到过)。我们还将免费赠送一本名为《同行代码审查的最佳保留的秘密》的书。从与客户的合作以及其他文献中我们学到了一些最佳的最佳实践。

以下是一些要点：

• 保持代码审查小。一次太多的代码是压倒性的，因此，如果评论中包含太多的代码，则应更频繁地以较小的块进行评论。
• 让所有人参与，但不要一次全部参与。代码审查为每个人(学习者和作者)提供了学习的机会。
• 记住，这是关于代码的，而不是关于作者的。