如果你配对程序，你还需要同行评审吗？

Question

我认为一般来说，Peer评论是开发过程的一个很好的部分，它们经常会抓住或质疑在最初编写代码时不明显的事情，并使你更加自我意识，以便你更好地格式化，发表评论等。< / p>

但是，如果你是成对编程，你实际上有一个实时的同行评审，那么作为这个过程的一部分，还值得同行评审吗？你有同伴评论吗？

我问，因为结对编程在我工作的地方开始发生，通常这被视为同行评审的替代品。我不太确定，但认为开发人员花在结对编程和同行评审上的时间可能会损害生产力。

前一段时间有similar question，但重点不同，没有明确的共识

Answer 1

这取决于。

在我看来，同行评审的目标不仅是直接找到写入代码的缺陷，而且要确保代码也能与现有的代码库一起使用。有时，您可能希望涉及您正在编写的代码的专家，并且可能不是该对代码的成员。

例如，如果您编写应用程序的3D图形部分，您可能希望由OpenGL专家对其进行检查。

因此，根据具体情况，您可能需要第三双眼睛来查看您的问题。这个人甚至可能不会并置（在另一个时区或其他什么地方）。

另外，当你配对时，你可能会有相似的倾向。因此，另一种观点可能会让你睁开眼睛看错过的东西。

如果我的开发人员配对代码，如果他们不是该代码的100％专家，我仍然会煽动他们审查他们的代码。

Answer 2

如果合作伙伴改变了对编程，那么你基本上会自动进行同行评审（甚至不仅仅是一对“额外”的眼睛）。如果两个程序员都不确定如何做某事，他们可以（应该）仍然寻求帮助，这又会导致某种同行评审。

Answer 3

我认为同行评审仍然很重要，因为在两种情况下涉及的思维模式在编程时都非常不同正常的思维模式并不重要，而在进行同行评审时，这种思维方式与批评分析一样，就像获取手册一样由开发它的同一个开发人员完成的测试不如从测试人员完成测试那么好

Answer 4

配对切换旨在解决同行评审的问题。当开发人员加入新对时，他/她必须了解他/她将要处理的问题。理解包括审查。

我认为只需要对系统的关键点进行单独的专家评审。

Answer 5

Paring是同行评审。或者正如XP所说，如果事情是好的，那就把它带到极致。如果同行评审是好的，那就连续进行，即结对编程。

当配对编程正确完成并且频繁旋转对时，您将完成所有开发代码的持续同行评审。更好的是，代码在设计，测试和编写时进行了审核（是的，首先编写测试A.K.A测试驱动开发），而不是在代码编写完成后修复更昂贵。

同行评审代码只是结对编程的一个优点。其他优点是：

提高质量：在同一故事卡上工作的一对活跃程序员将完成卡片的缺陷更少

提高生产力：如果在解决问题时没有完全阻止，则一对不太可能减速。此外，当您与合作伙伴合作时，更难以接受电子邮件或网络假期......您不想让合作伙伴失望。您可以使用更简洁的设计解决问题，并在成对工作时使用更少的代码行

消除知识孤岛：通过轮换对，您将学习整个团队的应用程序和域业务知识。由于苏去度假而没有其他人知道她的代码，团队不太可能被封锁。

技能转移：轮换对在他们协同工作时互相教授新技能（工程和领域）。每个人的团队水平都会提高，知识会通过团队传播。

团队自我选择：团队学习一个花药的技能，并迅速淘汰那些没有表现的人。