就我自己而言，我们的开发团队对许多不同的软件工件（需求分析，测试计划，代码等）进行了同行评审。同行编程甚至不被视为一种选择。
同行评审实践从顶部被推倒，开发者从未接受过。我们有一个外部SQA小组，从活动中收集指标，但由于努力是半心半意，这些数字是相当无价值的。经过多年这种“官方”的做事方式，开发商已经集体忽视了规定的程序。
现在，对于何时将错误插入生命周期的可见性较低。不进行同行评审导致团队专业化程度提高......没有人真正了解系统专用区域之外的组件要求/逻辑。
了解您的同伴评论或结对编程的经历，尤其是成功案例，将会很有价值。
答案 0 :(得分：22)
当我年轻而愚蠢的时候，我的第一份工作之一就是建立一个解析器来拉出长文件中的某些字段，这些文件被转储到无格式文本中。我知道足够使用某种形式的正则表达式，但还不足以完成正则表达式的正则表达式。几天后，我完成了任务，但在同行评审中，我被压得知道我本可以做得更好，我制作的是垃圾。我学会了如何进行词法解析只是为了证明我不是白痴，但只是说同行评审过程很糟糕。我不需要一个资深人士为我的失败而跳舞，我需要一位导师，每次我做同行评审时我都会提醒自己。
当我们检查门口的自负时，我喜欢同行评审。 （这包括我的！）这个世界上有一段有限的时间，只有你可以学习和做的事情。通过良好的同行评审，您可以扩展您的知识，并在更短的时间内完成更多工作。当事情降级为过度肛门语法检查时出现问题。
因此我有一些规则。我不会同意审查任何可以自动化的内容。运行拼写检查，并编码美化。如果您有类似FXCop的东西可以使用，可以运行它，按照它说的去做，或者为什么不这样做有一个很好的理由。然后我们可以看看代码是如何组合在一起的，它是如何运作的以及我们可以做些什么来改进代码。通过这种方式，您可以获得关于如何解决问题的不同观点以及为什么有人这样想。有时候另一种方式并不是真的更好，有时候新的解决方案非常棒，你可以用它来为你的其他人编程生活。 一旦审查完成，就是这样，我不是以它为例来反对你。你可以从中学到它的意义。我不会因恐惧或威胁来管理，你是一个聪明的人，我会让你展示它。
答案 1 :(得分：11)
我们尽量确保在没有通过至少另一双眼睛的情况下没有代码投入生产 通常，这意味着我们进行代码审查。我们试图让团队成为习惯，审核是编写代码的固有部分。你写下来，然后问别人的意见 此外，在我们有足够人员可用的项目中（当任务大小合适时），我们尝试配对编程 我必须说我们确实看到了这方面的优势。首先，这是指导团队中初级开发人员的好方法 - 当您查看他们的代码时，您可以向他们展示可以做得更好的事情，并且在与他们配对时，他们可以看到更好的做事方式，经验丰富的人思考甚至如何更好地使用IDE 此外，它使整个团队保持同步，只要知道代码的外观 而且，它只会增加每个人的快乐和个人发展 - 一个能够谈论和推理代码的团队是一个更好的团队，一个不断学习和分享的团队。
需要注意的一些事项：
答案 2 :(得分：4)
同行评审应强制性。
您可以阅读和查找大量文章和书籍，讨论在不同规模的团队中处理此问题的不同方法，但您似乎在询问体验。
就个人而言，我认为同行评审应该变得有趣。提供的食物和保持气氛愉快。它应该被视为一个开发人员/程序员可以相互学习而不是判断机会的时间（而且我们都知道每个程序似乎都是天生的判断基因）。我倾向于欣赏或协助组织评论为1/3或1/4的时间开放。我的意思是当小组聚集在一起，一个人提出他们正在工作或甚至审查的项目时甚至与当前项目无关（我知道这很难在最后期限但是尝试它）。
广告素材通常会聚集在一起展示他们目前所处的绘画，设计和艺术家，以帮助提升灵感。实际上，灵感应该是您希望在评论中培养的主要概念。除此之外，人们自然会注意到他们的开发人员所做的事情，他们以前没有注意到。 “哦，哇，所以你设法在一行代码中做到了这一点？很酷。“让开发人员对他们所做的事情，他们正在做的事情以及他们如何开展工作的启发和激励将比使用同行评审确定啄食顺序和排名更能带来红利。
最后，实际上是“审查”部分，但这是一个不可避免的事实。你的更好的开发人员会看到糟糕的代码，经过足够的评论后，这个可怜的程序员可能会升级或忘记它。
如果你把事情保持积极和有条理，通常会有很好的经验。
几乎忘了触摸对编程。设置起来比较困难。显然，你不能让两个较弱的程序员一起工作，或者你也可以安排一百万只拥有一百万打字机的猴子。尝试让一个更强壮的人更弱，并为私人提供激励。更弱的人应该知道改善可以得到回报（如果他们需要这样的激励），而更强大的程序员应该知道真正的领导者应该是良好的导师。确保较弱的开发人员输入。反之亦然，或者它变成了一个演示文稿，“打哈欠”某人可能无法获得任何经验。
答案 3 :(得分：4)
我做了一堆敏捷教练，为了帮助人们克服对编程的“耻辱”，我们称之为“实时代码和设计评审”。人们似乎更好地理解了这个概念。
答案 4 :(得分：2)
我唯一直接相关的经验是同行设计评论（很久以前）。而且他们很糟糕。如果你阅读文献，很明显他们违反了几条好的评论规则（跳过人，专注于拼写，没有明确的结果等等），但这只是我们所知道的。
但是从那以后我参与了大量的离线代码审核。
根据项目，他们要么在登记到“实时”分支之前被要求，要么在之后的某个随机时间点被强制要求。在4个项目中的3个项目中，他们已被接受，最初被认为是一个必要的邪恶，但后来作为一个有价值的投入。
任何工作评论的好处应该是让每个人都写出更好的代码并给出最好的编码指导（说实话，你的热门程序员真的会编写可读的代码吗？）一旦你能说服经验不足的员工说出他们的话不明白的东西 - 你离开了。一些热门镜头会让人气喘吁吁。吹，但实际上最好的人会考虑他们写的东西，实际上改变变量名称或布局 - 甚至可能添加评论。
第四个项目使用强制方案“随机时间”进行审查，技术线索尚未进入（破碎的团队？）
您描述的两种做法是正式方法。它们不适合所有个性和群体。
尝试一些您认为团队可以实际做的事情，然后看看是否可以改进。
一旦你对你的代码有额外的眼睛，你就不想回头了
答案 5 :(得分：2)
•是的，我们公司使用同行代码审查。我们将其作为Over-The-Shoulder进行评审，并邀请团队的测试人员参加会议，以更好地了解变化。
•一些研究已经证明，代码审查有一定的好处。对于我们公司来说，很明显代码质量随着支持呼叫数量的减少而增加，报告的错误数量也减少了。注意：这里的一些好处是实现Scrum和放弃Waterfall的结果。更多关于Scrum的信息。
•代码审查的好处可以是更稳定的产品，更易于维护的代码，因为它适用于结构和编码标准，并且它允许开发人员更多地关注新功能而不是“消防”错误，以及其他生产的问题。如果代码审查是“正确的”，那么确实没有任何缺点。更多关于下面的“正确方法”。
•在实施代码审查时要克服的一些障碍是“大哥”正在关注我的想法以及没有完美代码意味着折磨和痛苦的想法。让开发人员彼此信任是很困难的，特别是当涉及“啄食顺序”或“比你更圣洁”的态度并将你的辛勤工作放在显微镜下时。信任是解决这些问题的关键。开发人员必须相信，对于代码中的错误，他们不会受到同事或管理层的惩罚。它发生在每个人身上。记下问题，解决问题并继续前进。
<强>的Scrum 使用Scrum方法的一个好处是开发周期（“sprint”）很短。 “冲刺”的时间范围取决于哪种方式最适合您的组织，需要一些试验和错误，但实际上不应超过四周的迭代次数。好处是它需要开发人员每天进行通信并在项目早期就沟通问题。这最初是由我们的开发部门采用的，并且已经扩展到我们公司的所有领域，因为scrum的好处是深远的。有关详细信息，请参阅：http://en.wikipedia.org/wiki/SCRUM或http://www.scrumalliance.org/。由于开发迭代较小，代码审查过程会审查较小的代码片段，使得审核更容易发现问题，而不是数小时或数天的正式审核。
“正确的方式” 完成“正确方式”的代码审查是完全主观的。但是，我个人认为他们应该是非正式的，过分的评论。审查中的所有参与者都应该避免使用诸如“你为什么这样做？”或“你在想什么？”等陈述来亲自攻击被审查人。这些类型的评论减少了同行之间的信任，导致仇恨，争论解决方案的最佳/正确方式的几个小时。请记住，开发人员不会想到或编码完全相同，并且有许多解决问题的方法 稍微澄清一下肩负的评论;这些可以通过远程桌面共享（在这里选择风味）或亲自进行。但是，它们不应仅限于开发人员。我们通常邀请我们的整个Scrum团队，每个团队包括两名开发人员，一名测试人员，一名文档人员和产品负责人。所有非开发人员都可以更好地了解所做的更改或新功能。他们可以自由提问或提供意见，但不能做出编码决定或评论。这是有效的，因为某些问题可能会改变项目的方向，因为最初的要求可能已经错过了一个场景，但这就是敏捷的全部，改变。
<强>建议 在强制要求之前，我强烈建议研究Scrum和代码审查。为每个项目创建基本规则，并将其作为您文化的一部分来实施，以获得更高质量的产品。它必须成为您文化的一部分，以便它成为自然过程的一部分并融入各个层面，因为它是从质量差，错过最后期限和挫折到更高质量的产品，更少的挫折和更多准时交付的范式转变
答案 6 :(得分：0)
从配对编程转移到github上的PR评论之后的比较分析。
重点是逐步列出我们的团队现在在PR审核流程中遵循的内容。
“代码评论与结对编程”https://blog.mavenhive.in/pair-programming-vs-code-reviews-79f0f1bf926