如果你配对程序,你还需要同行评审吗?

那要视情况而定。

在我看来,同行评审的目标不仅是直接发现编写的代码的缺陷,而且要确保代码也能与现有的代码库很好地协同工作。有时,您可能想让您正在编写的代码的专家参与进来,而该专家可能不是这对代码的成员。

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

因此,根据具体情况,你可能需要第三双眼睛来观察你的问题。这个人甚至不可能被搭配(在另一个时区或其他地方)。

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

如果我的开发人员与代码配对,如果他们不是代码的100%专家,我仍然会鼓励他们对代码进行审查。

如果合作伙伴在结对编程中发生变化,那么您基本上可以自动进行同行评审(甚至不止一对“额外”眼睛)。如果两个程序员都不确定怎么做,他们可以( 应该 )仍然需要帮助,这又会导致某种同行评审。

我认为同行评审仍然很重要,因为在这两种情况下涉及到的思维模式在编程时是相当不同的。在进行同行评审时,正常的思维模式并不重要。invloves的思维模式是关键性分析,就像让开发它的同一个开发人员进行手动测试一样,不会像通用电气那么好。在测试仪上进行测试

成对交换 旨在解决同行评审的问题。当开发人员加入新的团队时,他/她必须理解他/她将要处理的问题。理解包括回顾。

我认为只有对系统关键点的独立专家评审才是必需的。

帕林是同行评审。或者正如xp所说,如果某件事情是好的,那么就把它推向极端。如果同行评审是好的,那么就要不断地进行,即配对编程。

当配对编程完成并频繁地旋转配对时,您将完成所有开发代码的连续同行评审。更好的是,在设计、测试和编写代码时(是的,先编写测试A.K.A测试驱动开发),而不是在编写代码之后进行审查,并且修复成本更高。

同行评审的代码只是对编程的一个优势。其他优势包括:

提高质量 :一对在同一故事卡上工作的活跃程序员将以较少的缺陷完成该卡。

提高生产力 :如果在解决问题时没有完全阻塞,则对的减速可能性较小。此外,当你和合作伙伴一起工作时,很难接受电子邮件或网络假期…你不想让搭档失望。当您成对工作时,您将使用更简洁的设计和更少的代码行来解决这个问题。

消除知识孤岛 :使用旋转对,您将在整个团队中学习应用程序和域业务知识。因为苏去度假,其他人都不知道她的密码,所以团队不太可能被封锁。

技能转移: 旋转对在一起工作时互相教授新的技能(工程和领域)。团队的水平将为每个人提高,知识将通过团队传播。

团队自我选择: 这个团队学习另一个人的技能,很快就会淘汰出一个没有表演的人。