我认为一般来说,同行评审是开发过程中非常好的一部分,他们经常会发现或质疑最初编写代码时不明显的事情,并使您更加自觉,因此您可以更好地格式化,发表评论等。
然而,如果你是结对编程,你实际上有一个实时的同行评审,那么作为流程的一部分,还值得有一个同行评审吗?您可以进行配对同行评审吗?
我问,结对编程开始在我工作的地方发生,通常这被视为同行评审的替代品。我不太确定,但认为开发人员花在结对编程和同行评审上的时间可能会损害生产力。
前段时间有一个类似的问题,但重点不同,没有明确的共识
我认为一般来说,同行评审是开发过程中非常好的一部分,他们经常会发现或质疑最初编写代码时不明显的事情,并使您更加自觉,因此您可以更好地格式化,发表评论等。
然而,如果你是结对编程,你实际上有一个实时的同行评审,那么作为流程的一部分,还值得有一个同行评审吗?您可以进行配对同行评审吗?
我问,结对编程开始在我工作的地方发生,通常这被视为同行评审的替代品。我不太确定,但认为开发人员花在结对编程和同行评审上的时间可能会损害生产力。
前段时间有一个类似的问题,但重点不同,没有明确的共识
那要看。
在我看来,同行评审的目标不仅是直接发现编写代码的缺陷,而且要确保代码也能与现有代码库一起正常工作。有时,您可能希望让您正在编写的代码的专家参与其中,而他可能不是该组合的成员。
例如,如果您编写应用程序的 3D 图形部分,您可能希望 OpenGL 专家对其进行审核。
因此,根据具体情况,您可能需要第三双眼睛来看待您的问题。这个人甚至可能没有被并置(在另一个时区或其他地方)。
另外,当你配对时,你可能会有相似的想法。因此,另一种意见可能会让您对错过的事情大开眼界。
如果我的开发人员与代码配对,如果他们不是 100% 的代码专家,我仍然会鼓励他们审查他们的代码。
如果合作伙伴在结对编程中发生变化,那么您基本上会自动获得同行评审(甚至不仅仅是一对“额外”的眼睛)。如果两个程序员都不确定如何做某事,他们仍然可以(应该)寻求帮助,这再次导致某种同行评审。
我认为同行评审仍然很重要,因为这两种情况下涉及的思维定势在编程时非常不同,正常思维定势在进行同行评审时并不重要,涉及的思维方式是批判性分析,就像通过手动测试完成开发它的同一个开发者不如从测试人员那里完成它
配对交换旨在解决同行评审的问题。当开发人员加入新对时,他/她必须了解他/她将要解决的问题。理解包括审查。
我相信只需要对系统的关键点进行单独的专家审查。
配对是同行评审。或者正如 XP 所说,如果有什么好的,那就把它发挥到极致。如果同行评议很好,那就继续做,即结对编程。
当配对编程正确完成并且配对经常轮换时,您将完成对所有开发代码的持续同行评审。更好的是,代码在设计、测试和编写时进行审查(是的,首先编写测试,AKA 测试驱动开发),而不是在编写代码并且修复成本更高之后。
同行评审的代码只是结对编程的优势之一。其他优点是:
提高质量:一对活跃的程序员在同一张故事卡上工作,完成卡时缺陷更少
提高生产力:在解决问题时,如果没有完全阻塞,则一对不太可能放慢速度。此外,当您与合作伙伴一起工作时,更难通过电子邮件或网络度假……您不想让合作伙伴失望。成对工作时,您将通过更简洁的设计和更少的代码行来解决问题
消除知识孤岛:通过轮换对,您将在整个团队中学习应用程序和领域业务知识。该团队不太可能被阻止,因为 Sue 去度假了,没有其他人知道她的代码。
技能传授:当他们一起工作时,轮换的两人互相传授新技能(工程和领域)。每个人的团队水平都会提高,知识会通过团队传播。
团队自我选择:团队学习一个花药的技能,并迅速淘汰表现不佳的人。