在我自己的案例中，我们的开发团队对许多不同的软件工件（需求分析、测试计划、代码等）进行了同行评审。对等编程甚至不被视为一种选择。
同行评审实践是自上而下的，开发人员从未接受过它。我们有一个外部 SQA 小组从活动中收集指标，但这些数字毫无价值，因为这项工作是半心半意的。经过多年的“官方”做事方式，开发人员已经开始集体无视规定的程序。
现在，对于错误何时插入生命周期的可见性降低了。不进行同行评审导致团队专业化程度提高……没有人真正了解系统专业领域之外的组件的需求/逻辑。
了解您在同行评审或结对编程方面的经验，尤其是成功案例，将是很有价值的。
当我年轻而愚蠢的时候，我的第一份工作是构建一个解析器，以提取一个长 pdf 文件中的某些字段，该文件被转储为未格式化的文本。我知道足以使用某种形式的正则表达式，但对正则表达式的了解还不足以做好这项工作。几天后我完成了任务，但在同行评审中，我得知我本可以做得更好，而我制作的却是垃圾，我感到很沮丧。我学会了如何进行词法解析只是为了证明我不是白痴，但可以说同行评审过程很糟糕。我不需要一位资深人士来为我的失败跳舞，我需要一位导师，而且每次我进行同行评审时都会提醒自己这一点。
当我们在门口检查自我时，我喜欢同行评议。（这包括我的！）这个世界上的时间是有限的，只有这么多你可以学习和做。通过良好的同行评审，您可以扩展您的知识并在更短的时间内完成更多工作。当事情退化为过度的语法检查时，就会出现问题。
因此，我有一些规则。我不会对任何我们可以自动化的东西进行同行评审。运行拼写检查和代码美化器。如果您有类似 FXCop 的东西可供您使用，请运行它，按照它所说的去做，或者有一个很好的理由说明您不能使用它。然后我们可以看看代码是如何组合在一起的，它是如何工作的，以及我们可以做些什么来改进它。通过这种方式，您可以从不同的角度了解如何解决问题以及为什么有人会这样想。有时另一种方法并不是真的更好，有时新的解决方案非常棒，你将在你的余生中使用它。一旦审查完成，就是这样，我不会用它作为反对你的例子。你可以从中学习到什么。我不会通过恐惧或威胁来管理，你是一个聪明的人，我会让你展示出来。
我们试图确保在没有经过至少另一双眼睛的情况下，任何代码都不会投入生产。
通常，这意味着我们进行代码审查。我们试图让团队养成一种习惯，即审查是编写代码的固有部分。你写它，然后征求某人的意见。
此外，在我们有足够人可用的项目中（当任务规模合适时），我们会尝试结对编程。
我必须说，我们肯定已经看到了这样做的优势。首先，这是指导团队中初级开发人员的好方法 - 当您审查他们的代码时，您可以向他们展示可以做得更好的地方，并且在与他们配对时，他们可以看到更好的做事方式，人们的经验思考甚至如何更好地使用 IDE。
此外，就代码的外观而言，它使整个团队保持同步。
此外，它只会增加每个人的快乐和个人发展——一个能够谈论和推理代码的团队是一个更好的团队，一个不断学习和分享的团队。
需要注意的一些事项：
同行评审应该是强制性的。
您可以阅读并找到许多文章和书籍，这些文章和书籍讨论了在各种规模的团队中解决此问题的不同方法，但您似乎在询问经验。
就个人而言，我认为同行评审应该变得有趣。提供食物并保持气氛愉快。它确实应该被视为开发人员/程序员可以相互学习而不是评判的机会（我们都知道每个程序似乎天生就具有先天的评判基因）。我倾向于欣赏或协助将评论组织为开放时间的 1/3 或 1/4。我的意思是当团队聚集在一起时，一个人提出了一个他们正在工作甚至审查的项目，该项目甚至与当前项目无关（我知道这在截止日期方面很困难，但尝试一下）。
创意人员通常聚在一起展示他们目前喜欢的绘画、设计和艺术家，以帮助激发灵感。实际上，灵感应该是您希望在评论中培养的主要概念。其次，人们会自然而然地注意到他们的开发人员所做的事情，而这些事情他们以前没有注意到。“哦，哇，所以你用一行代码就做到了？凉爽的。” 让开发人员对他们所做的事情、他们正在做什么以及他们如何去做这件事获得灵感和动力，这将比使用同行评审来建立优先顺序和排名更能带来回报。
最后是真正的“审查”部分，但这是不可避免的事实。更好的开发人员会看到糟糕的代码，经过足够多的审查后，糟糕的程序员要么升级，要么忘记它。
如果你保持积极和有条理，这通常是一次很棒的经历。
差点忘了讲结对编程。这更难设置。显然，您不能让两个较弱的程序员一起工作，或者您不妨安排一百万只猴子和一百万台打字机。试着让一个更强大的人与一个更弱的人在一起，并私下为他们提供激励。较弱的人应该知道改进可以得到回报（如果他们需要这样的激励），而强大的程序员应该知道真正的领导者从好的导师开始。确保较弱的开发人员正在打字。反之亦然，否则它会变成一个演示文稿，并且“打哈欠”某人可能不会从经验中获得任何收益。
我做过很多敏捷教练，为了帮助人们克服结对编程的“耻辱”，我们称之为“实时代码和设计审查”。人们似乎更好地理解了你用这些术语表达的概念。
我唯一直接相关的经验是同行设计评审（很久以前）。他们糟透了。如果你阅读文献，很明显它们违反了好评论的几条规则（跳到人身上，专注于拼写，没有明确的结果等），但这是我们所知道的。
但从那以后，我参与了大量的离线代码审查。
根据项目，他们要么在签入“实时”分支之前被强制执行，要么在之后的某个随机时间点被强制执行。在 4 个项目中的 3 个项目中，它们被接受，最初被认为是必要的邪恶，但后来作为有价值的输入。
任何工作审查的好处应该是让每个人都编写更好的代码，并为最好的程序员提供指导（老实说，你的热门程序员真的写可读的代码吗？）一旦你可以说服经验不足的员工说他们没有明白一些事情——你走了。一些热门镜头会吹嘘，但真正最好的镜头会考虑他们所写的内容并实际更改变量名称或布局 - 甚至可能添加评论。
第 4 个项目使用“随机时间”审查的强加方案，技术主管尚未参与其中（破碎的团队？）
您描述的两种做法是正式的方法。它们不适用于所有个性和群体。
尝试一些你认为你的团队实际上可以做的事情，然后看看它是否可以改进。
一旦你对你的代码有了额外的关注，你就不想回头了
从结对编程转到 github 上的 PR 评论后的比较分析。
重点是逐步列出我们的团队现在在 PR 审查过程中遵循的内容。
“代码审查与结对编程” https://blog.mavenhive.in/pair-programming-vs-code-reviews-79f0f1bf926