你的代码评论涉及什么和哪些模式是成功的？

Question

我想更好地理解可以工作的模式以及不适用于成功代码审查的模式。

1. 如果有一个差别是一个正式的代码审查和非正式代码审查？

2. 人们在做什么级别的代码审查文档？

3. 如果没有代码参与者的作者，代码评审能够有用吗？

Answer 1

我不认为应该有正式和非正式的，因为有不同类型的时间允许代码审查。如果有一个错误需要尽快解决，并且代码更改只是几行代码，则可能仍会进行审核，但可能与采用新的ERP或CRM系统的方式不同。此外，在某些情况下可能需要花费数小时来查看某些代码，而在其他情况下，应该花费不到5分钟的时间。

的文档可以在几个形式。它可能只是一封电子邮件，称Joe对Bob的工作进行了审查，并且已批准这项工作进入下一阶段发布。或者，在推广代码之前，可能需要几页关于更改内容的注释，以便使用某些设计模式，并将代码从其最初的快速和肮脏的表单中清除。

至于最后一个问题，我想答案是有时。如果你有，你想如何优化的代码，那么不必笔者参加可能在获得帮助的想法，然后有笔者要么作出改变或解释为何更改不会改善其他人的意见的一些代码代码，例如如果有人想加入冒泡排序算法，这可能会被拒绝，因为其他更有效的排序算法，如quicksort，mergesort和heapsort。

编辑，以添加一对夫妇的模式，我发现有用： 对于bug修复代码审查，我最喜欢的模式是： 1）显示的bug在测试/临时环境，这样我可以看到什么出错。 2）告诉我代码被更改的位置，以及为什么以这种方式更改代码的简要说明。 3）告诉我代码在本地机器上是固定的。

相反，如果一个实现与十多位方法的API，然后它可能是最好有一些文档，总结什么是在实现中使用，为什么一些选择进行了改造，例如使用什么样的列表实现，如数组，哈希表，链表，通用列表，堆栈，队列等。

Answer 2

首先看看Fagan inspections的概念。

这种方法真的有助于审查代码的质量，而审查本身实际上！

永远记得批评代码而不是编码器。

Answer 3

使用Eclipse Jupiter plugin并遵循它自动化的过程对我们来说工作得非常好。这不是太侵入或官僚主义，但它仍然真的有助于发现错误和设计问题。

Answer 4

我所做过的最好的代码评论涉及到一个名为Smartbear的代码协作者的工具。 作者将代码上传到服务器。审稿人和观察员可以看到新代码和旧代码之间的差异，并对新代码发表评论。 这里是最好的做法：

1. 书面给一个线索从哪里开始审阅代码作者的意见。
2. 评论者评论并添加需要在接受评论前修复的缺陷。只有重要的事情应该被标记为缺陷。没有错别字或你知道开发人员在提交之前修复的东西。
3. 将新开发人员作为观察员参与。这是让他们熟悉项目的良好培训。
4. 在这段代码中包含“专家”，作为观察者或审阅者。

反模式：

1. 使用代码检查工具的设计审查工具。这不适合。只能查看已经就设计达成一致的代码。
2. 涉及太多审阅者和观察者
3. 让审查在系统中逗留超过几天。

Answer 5

我觉得是好的代码审查的关键模式是的时间和动机，真正阅读和理解的代码评审有程序员。只给予代码粗略观察并指出一些代码样式更改的审阅者并不真正参与该过程。

Answer 6

• 定期和频繁地安排审查或检查 。 回顾/检查整个模块时 新，和delta +周围 代码进行维护。建立积压的待审核内容使整个过程变得恐怖。

• 每个人的代码被审查，从 最初级到最高级， 和未经指责的恐惧 评论。

• 不要只审查/检查代码;在测试（特别是TDD）和 测试结果看 。我们检测 通过发现一些有趣的bug和测试 遗漏什么 我们认为我们的测试是不是真的 什么正在测试，或 ，我们就会在不经意间使用的测试来自同一个等价类 时 数据我们认为我们正在使用不同种类的数据。

Answer 7

我的公司，智能熊使代码合作者（如David Segonds所述）。我们还赠送了一本名为Best Kept Secrets of Peer Code Review的免费书。我们从与客户合作以及查看其他文献中获得了一些良好的最佳实践。

这里有几点：

• 保持代码审查小。一次编写的代码太多了，因此如果您的评论代码太多，请以更小的代码块进行更频繁的查看。
• 让所有人参与，但不是一次全部参与。代码审查是每个人都可以学习的机会，审稿人和作者都是如此。
• 请记住，这是关于代码，而不是关于作者。