同行评审或结对编程，或两者兼而有之？[关闭]

Question

• 您是否参加代码同行评审或练习结对编程，或两者兼而有之？
• 您是否能够证明使用这些实践可以提高软件质量？
• 您在实践过程中观察到哪些优点和缺点？
• 您在实施过程中遇到了哪些障碍？

就我自己而言，我们的开发团队对许多不同的软件工件（需求分析、测试计划、代码等）进行了同行评审。同行编程甚至没有被视为一种选择。

同行评审的做法是自上而下的，开发商从来不买账。我们有一个外部 SQA 小组从活动中收集指标，但这些数字毫无价值，因为我们的努力是半心半意的。经过多年这种“官方”做事方式之后，开发人员已经集体忽视了规定的程序。

现在，对于错误何时被插入生命周期的可见性越来越低。不进行同行评审会导致团队的专业化程度提高……没有人真正了解自己的系统专业领域之外的组件的需求/逻辑。

了解您的同行评审或结对编程的经验，尤其是成功的故事，将会很有价值。

Answer 1

当我年轻而愚蠢时，我的第一份工作就是构建一个解析器，以提取一个长 pdf 文件中的某些字段，该文件被转储为未格式化的文本。我对使用某种形式的正则表达式有足够的了解，但对正则表达式的了解还不足以做好这项工作。几天后，我完成了任务，但在同行评审中，我很沮丧地发现我可以做得更好，但我制作的东西却是垃圾。我学会了如何进行词法解析只是为了证明我不是白痴，但只能说同行评审过程很糟糕。我不需要一个资深人士来为我的失败而跳舞，我需要一个导师，每次我进行同行评审时我都会提醒自己这一点。

当我们在门口检查自我时，我喜欢同行评审。（这包括我的！）这个世界上的时间是有限的，你可以学习和做的时间也是有限的。通过良好的同行评审，您可以扩展知识并在更短的时间内完成更多工作。当事情退化为过度语法检查时，问题就会出现。

因此，我有一些规则。我不会对任何我们可以自动化的东西进行同行评审。运行拼写检查和代码美化器。如果您有类似 FXCop 之类的东西，请运行它，按照它的说明进行操作，或者有充分的理由不这样做。然后我们可以看看代码是如何组合在一起的、它是如何运作的以及我们可以做些什么来改进它。通过这种方式，你会对如何解决问题以及为什么有人这么想有不同的看法。有时另一种方法并不是更好，有时新的解决方案非常棒，并且您将在余下的编程生涯中使用它。一旦审查完成，就是这样，我不会拿它来作为针对你的例子。你可以从中学到什么。我不会通过恐惧或威胁来应对，你是一个聪明的人，我会让你展示这一点。

Answer 2

我们尽力确保任何代码在未经至少另一双眼睛检查的情况下都不会投入生产。
通常，这意味着我们进行代码审查。我们努力让团队形成一种习惯，即评审是编写代码的固有部分。你写下来，然后征求别人的意见。
此外，在我们有足够人员可用的项目中（当任务大小合适时），我们尝试结对编程。
我必须说我们确实看到了这一点的优势。首先，这是指导团队中的初级开发人员的好方法 - 当您审查他们的代码时，您可以向他们展示可以做得更好的地方，当与他们结对时，他们可以看到更好的做事方法，经验丰富的人如何做思考甚至如何更好地使用IDE。
此外，它还可以让整个团队保持同步，了解代码的外观。
而且，它只会增加每个人的快乐和个人发展——一个能够谈论和推理代码的团队是一个更好的团队，一个不断学习和分享的团队。

需要注意的一些事项：

• 确保高年级学生在结对时也让低年级学生编程
• 不要让人们结对执行小任务，通常会浪费时间
• 观察两人如何相处（不要强迫两人在一起）
• 记得时不时地重新洗牌
• 不要让评论成为自我匹配——不要让人们压垮别人

Answer 3

同行评审应该是 强制的.

您可以阅读并找到大量文章和书籍，这些文章和书籍讨论了在不同规模的团队中解决此问题的不同方法，但您似乎在询问经验。

就我个人而言，我认为同行评审应该变得有趣。提供食物并保持愉快的气氛。它确实应该被视为开发人员/程序员可以互相学习的时间，而不是判断的机会（我们都知道每个编程人员似乎天生就带有天生的判断基因）。我倾向于欣赏或协助将评论组织为开放时间的 1/3 或 1/4。我的意思是，当团队聚集在一起，一个人提出一个他们正在工作甚至正在审查的项目时，该项目甚至与当前项目无关（我知道这在截止日期前很困难，但请尝试一下）。

创意人士通常会聚在一起展示他们目前感兴趣的绘画、设计和艺术家，以帮助激发灵感。实际上，灵感应该是您希望在评论中培养的主导概念。其次，人们会自然地注意到他们的开发人员同事所做的事情，而他们以前没有注意到。“哇哦，这么说你只用一行代码就能做到这一点？凉爽的。”让开发人员启发和激励他们对自己的工作，正在从事的工作以及如何进行启发，而与使用同行评审建立啄食顺序和排名相比，这会带来更多的股息。

最后，是真正的“审查”部分，但这是不可避免的事实。优秀的开发人员会看到糟糕的代码，经过足够的审查后，糟糕的编码员要么升级，要么忘记它。

如果你保持积极的态度并有条理，这通常是一次很棒的经历。

差点忘了谈结对编程。这设置起来比较困难。显然你不能让两个较弱的程序员一起工作，或者你还不如安排一百万只猴子和一百万台打字机。尝试让较强的人与较弱的人一起工作，并私下为双方提供激励。较弱的人应该知道改进可以获得奖励（如果他们需要这种激励），而较强的程序员应该知道真正的领导者首先是好的导师。确保较弱的开发人员正在打字。反之亦然，否则它就变成了演示文稿，并且“打哈欠“某人可能不会从经验中获得任何东西。

Answer 4

我做过很多敏捷辅导，为了帮助人们克服结对编程的“耻辱”，我们称之为“实时代码和设计审查”。当你用这些术语来表达这个概念时，人们似乎会更好地理解它。

Answer 5

我所拥有的唯一直接相关的经验是同行设计评审（很久以前）。他们很糟糕。如果你读过文献，很明显他们违反了好评论的几条规则（跳到人身上、专注于拼写、没有明确的结果等。等等）但这就是我们所知道的一切。

但 从那时起我就参与了大量的离线代码审查。

根据项目的不同，它们要么在签入“实时”分支之前被强制执行，要么在之后的某个随机时间点被强制执行。在四分之三的项目中，它们被接受了，不可否认，最初它们是一种不可避免的罪恶，但后来却成为一种有价值的投入。

任何工作审查的好处应该是让每个人都写出更好的代码，甚至为最好的程序员提供指导（说实话，你的热门程序员真的写出可读的代码吗？）一旦你可以说服经验不足的员工说他们不这样做明白一些事情——你走了。一些热门人物会气喘吁吁，但真正最好的人会思考他们所写的内容，并实际更改变量名称或布局 - 甚至可能添加注释。

第四个项目使用“随机时间”审查的强制方案，并且技术主管尚未纳入其中（团队破裂？）

---

您描述的两种做法是正式方法。它们并不适合所有个性和群体。

尝试一些你认为你的团队实际上可以做的事情，然后看看是否可以改进。

一旦你对代码有了额外的关注，你就不会想回头看

Answer 6

• 是的，我们公司使用同行代码审查。我们以过肩审查的方式进行，并邀请团队的测试人员参加会议，以更好地了解变更。

• 多项研究已经证明，代码审查确实有好处。对于我们公司来说，随着支持电话数量的减少和报告的错误数量的减少，代码质量明显提高。笔记：这里的一些好处是实施 Scrum 和放弃瀑布的结果。更多关于 Scrum 的内容请参见下文。

• 代码审查的好处是可以提供更稳定的产品、更易于维护的代码，因为它适用于结构和编码标准，并且它允许开发人员更多地关注新功能，而不是“救火”错误和其他生产问题。如果代码审查“正确”进行，那么确实没有任何缺点。下面详细介绍“正确的方法”。

• 实施代码审查时需要克服的一些障碍是“老大哥”在监视我的想法以及没有完美代码意味着折磨和痛苦的想法。让开发人员相互信任有时很困难，特别是当它涉及“啄食顺序”或“比你更神圣”的态度以及将你的辛勤工作置于显微镜下时。信任是解决这些问题的关键。开发人员必须相信他们不会因为代码错误而受到同事或管理层的惩罚。每个人都会遇到这种情况。记下问题，解决它并继续。

Scrum使用 Scrum 方法的好处之一是开发周期（“冲刺”）很短。“冲刺”的时间框架取决于最适合您的组织的方式，并且需要一些尝试和错误，但实际上不应超过四个星期的迭代。好处是，它需要开发人员每天进行沟通，并在项目早期就问题进行沟通。这最初由我们的开发部门采用，并扩展到我们公司的所有领域，因为 Scrum 的好处是深远的。有关更多信息，请参阅： http://en.wikipedia.org/wiki/SCRUM 或者 http://www.scrumalliance.org/ 。由于开发迭代较小，代码审查过程会审查较小的代码片段，从而使审查比数小时或数天的正式审查更有可能发现问题。

“正确的方法”以“正确的方式”完成代码审查完全是主观的。然而，我个人认为它们应该是非正式的、实时的评论。审查中的所有参与者都应避免亲自攻击正在审查的人，例如“你为什么那样做？”或“你在想什么？” ETC。这些类型的评论削弱了同行之间的信任，导致敌意，导致人们为了编写解决方案的最佳/正确方法而争论数小时。请记住，开发人员的思维或代码并不完全相同，而且问题的解决方案有多种。
只是对过肩评论做一点澄清；这些可以通过远程桌面共享（在此处选择风格）或亲自进行。然而，它们不应仅限于开发人员。我们通常会邀请整个 Scrum 团队，每个团队由两名开发人员、一名测试人员、一名文档人员和产品负责人组成。所有非开发人员都可以更好地了解所做的更改或新功能。他们可以自由提出问题或提供意见，但不能做出编码决策或评论。这是有效的，因为会提出某些问题，这些问题可能会改变项目的方向，因为最初的需求可能错过了某个场景，但这就是敏捷的全部内容，即改变。

建议我强烈建议在强制执行之前研究一下 Scrum 和代码审查。为每个规则创建基本规则并将其作为您的文化的一部分实施，以实现更高质量的产品。它必须成为你的文化的一部分，这样它就成为一个自然过程的一部分，并在各个层面上进行整合，因为它是一种范式转变，从质量差、错过最后期限和挫折到更高质量的产品、更少的挫折和更多的按时交付。

Answer 7

从结对编​​程转到 github 上的 PR 评论后的比较分析。

重点是逐步列出我们的团队现在在公关审查流程中遵循的内容。

“代码审查与结对编程” https://blog.mavenhive.in/pair-programming-vs-code-reviews-79f0f1bf926