关于qa：同行评议或结对编程，或两者兼而有之？

Peer Reviews or Pair Programming, or Both?

您是否参加代码同行评审或实践结对编程，或两者都参加？
使用这些实践，您是否能够证明软件质量的提高？
您在练习过程中观察到了什么利弊？
您面临实施的哪些障碍？

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

同行评审的做法被推倒了，而开发人员却从不接受。我们有一个外部SQA小组，该小组从活动中收集指标，但是由于付出了三心二意，所以这些数字毫无价值。经过多年的"正式"做事方式，开发人员开始集体忽略规定的程序。

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

了解您的经验(同行评议或结对编程)，尤其是成功案例，将非常有价值。

当我年轻又愚蠢时，我的第一项工作是建立一个解析器，以提取长pdf文件中的某些字段，该文件被转储为未格式化的文本。我对使用某种形式的正则表达式了解得足够多，但对正则表达式的理解还不够。几天后，我完成了这项任务，但在同行评审中，我迷恋上得知我本可以做得更好，而我生产的却是垃圾。我学会了如何进行词法分析，只是为了证明我不是白痴，而只能说同行评审过程很糟糕。我不需要资深人士来为自己的失败做准备，我需要一位导师，而且我每次做同行评审时都想起自己。

当我们在门口检查自我时，我喜欢同行评议。 (这包括我的！)这个世界上的时间是有限的，只有那么多的时间，您才能学习和做。通过良好的同行评审，您可以扩展知识，并在较短的时间内完成更多工作。当事情降级为过度的语法检查时，就会出现问题。

因此，我有一些规则。我不会对任何我们可以自动化的内容进行审查。运行拼写检查，然后对美化器进行编码。如果您有可用的FXCop之类的东西，请运行它，按其说的做，或者有个很好的理由而不是。然后我们看一下代码是如何组合在一起的，它是如何工作的以及我们可以做些什么来改进它。通过这种方式，您对如何解决问题以及为什么有人这样认为有不同的看法。有时，另一种方法并不是真的更好，有时，新的解决方案很棒，并且在您余下的编程生涯中都会用到。
审核完成后就可以了，我不以它为例来对付您。学习您的经验是您的本分。我不会因恐惧或威胁而应付，您是一个聪明的人，我将向您展示。

我们试图确保没有至少一双眼睛就不会产生任何代码。
通常，这意味着我们编写代码审查。我们试图使团队中的一种习惯是：评审是编写代码的固有部分。您编写它，然后向某人征求意见。
同样，在项目中我们有足够的人员(当任务大小合适时)，我们尝试配对编程。
我必须说，我们绝对看到了这一点的优势。首先，这是指导团队中初级开发人员的好方法-当您查看他们的代码时，您可以向他们展示可以做的更好的事情，与他们配对时，他们可以看到做事的更好方法，有经验的人思考甚至更好地使用IDE。
而且，它可以使整个团队保持同步，以了解代码的外观。
而且，它只是增加了每个人的喜悦和个人发展-一支能够进行代码讨论和推理的团队是一个更好的团队，一个不断学习和共享的团队。

需要注意的一些事情：

确保老年人在配对时也让大三生编程
不要让人们在小任务上结伴，通常会浪费时间
观察配对如何相处(不要强迫配对)
记住要时不时地改组
不要让评论成为自我匹配的比赛-不要让别人粉碎别人

我做了很多敏捷指导，为了帮助人们克服结对编程的"烙印"，我们将其称为"实时代码与设计审查"。用这些术语来说，人们似乎对这个概念的理解更好。

同行评审应该是强制性的。

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

我个人认为同行评议应该很有趣。提供食物，保持气氛愉快。确实应该将其视为开发人员/编程人员可以相互学习而不是进行判断的机会的时间(而且我们都知道每个程序看起来都是天生具有判断力的基因)。我倾向于欣赏或协助组织评论(开放时间为第1/3或1/4)。我的意思是，当小组聚集在一起并且一个人介绍一个项目时，他们正在工作甚至正在审查与当前项目无关的项目(我知道这很难按时完成，但是请尝试)。

通常，创意人员会聚在一起展示他们目前所喜欢的绘画，设计和艺术家，以帮助激发灵感。实际上，灵感应该是您希望在评论中培养的领先概念。其次，人们自然会注意到其他开发人员所做的事情，而他们以前从未注意到过。"哦，哇，您设法用一行代码做到了吗？凉。"与使用同行评审来确定啄食顺序和排名相比，让开发人员对自己的工作，所做的工作以及如何做事有启发和动力，这将使分红更多。

最后，实际上是"审核"部分，但这是不可避免的事实。优秀的开发人员将看到质量低下的代码，经过足够的审查，现在是劣质编码者增强或忘记它的时候了。

如果您保持积极的态度并组织有序的活动，那通常是很棒的经历。

几乎忘了接触配对编程。这很难设置。显然，您不能让两个较弱的程序员一起工作，或者您最好安排一百万只猴子和一百万个打字机。尝试让一个较弱的人变得更坚强，并私下为他们俩提供激励。较弱的人应该知道可以得到改善(如果他们需要这样的激励)，而较强的程序员应该知道真正的领导者可以作为良好的导师开始。但是请确保较弱的开发人员正在键入。反之亦然，或者变成演示文稿，"打哈欠"的人可能无法从体验中获得任何收益。

？是的，我们公司使用同行代码审查。我们将其作为" Over-The-Shoulder"审查进行邀请，并邀请团队的测试人员参加会议，以更好地了解更改。

好的。

？正如一些研究已经证明的那样，代码审查有一定的好处。对于我们公司来说，很明显，随着支持电话数量的减少和报告错误的数量的减少，代码质量也得到了提高。注意：这里的一些好处是实施Scrum和放弃Waterfall的结果。有关Scrum的更多信息，请参见下文。

好的。

？代码审查的好处是可以使产品更稳定，代码更易于维护，因为它适用于结构和编码标准，并且允许开发人员将更多的精力放在新功能上，而不是"灭火"错误和其他生产问题上。如果"正确"进行代码审查，实际上没有任何缺点。更多关于下面的"正确方法"。

好的。

？实施代码审查时要克服的一些障碍是，"老大哥"在注视着我，而没有完美的代码则意味着折磨和痛苦。有时很难使开发人员彼此信任，尤其是在涉及"啄食顺序"或"比您更居高临下"的态度并将您的辛勤工作放在显微镜下时。信任是解决这些问题的关键。开发人员必须相信，他们不会因代码错误而受到同行或管理层的惩罚。它发生在每个人身上。记下该问题，使其解决并继续。

好的。

Scrum
使用Scrum方法的好处之一是开发周期("冲刺")很短。"冲刺"的时间范围取决于最适合您组织的情况，并且需要反复试验，但实际上不应超过四个星期。好处是，它要求开发人员每天进行沟通，并在项目早期就沟通问题。它最初是由我们的开发部门采用的，并且随着scrum的好处深远地影响到了公司的所有领域。有关更多信息，请参见：http://en.wikipedia.org/wiki/SCRUM或http://www.scrumalliance.org/。随着开发迭代次数的减少，代码审查过程将审查较小的代码段，与数小时或数天的正式审查相比，使审查更有可能发现问题。

好的。

"正确的方法"
完成"正确方法"的代码审查完全是主观的。但是，我个人认为，它们应该是非正式的，肩负重任的审查。评价中的所有参与者都应避免使用"为什么要这么做"这样的陈述来亲自攻击被评价者。或"你在想什么？"这些类型的注释会削弱同级之间的信任，从而导致仇恨，以及为解决方案编写最佳/正确方法而争论的时间。请记住，开发人员的想法或代码并不完全相同，并且有许多解决方案。
只是对肩上的评论做了一些澄清；这些可以通过远程桌面共享(在此处选择口味)或亲自进行。但是，它们不应该仅限于开发人员。我们通常邀请整个Scrum团队，每个团队由两个开发人员，一个测试人员，一个文档人员和产品所有者组成。所有非开发人员都可以在那里更好地了解所做的更改或进行的新功能。他们可以自由地提出问题或提供意见，但不能做出编码决定或评论。这是有效的，因为可能会问到某些问题，这些问题可能会改变项目的方向，因为最初的需求可能错过了一个方案，但这就是敏捷性的全部改变。

好的。

建议
我强烈建议在授权之前先研究scrum和代码审查。为每个规则创建基本规则，并将其作为您文化的一部分加以实施，以获取更高质量的产品。它必须成为您的文化的一部分，以便成为自然过程的一部分，并在各个层面进行整合，因为这是从不良质量，错过了最后期限和沮丧的范式转变到了质量更高的产品，更少的沮丧和更多的按时交付成果。

好的。

好。

我对两者的唯一直接相关的经验是同行设计评审(很久以前)。他们很烂。如果您阅读了这些文献，很明显，它们违反了良好评价的几条规则(跳人，专注于拼写，没有明确的结果等)，但这只是我们所知道的。

但是从那时起，我就参与了许多脱机代码审查。

根据项目的不同，它们要么在签入"活动"分支之前就已被强制执行，要么在之后的某个随机时间点被执行。在4个项目中，有3个被接受，最初被认为是必要的邪恶，但后来却成为了宝贵的投入。

任何工作审查的好处应该是使每个人都编写更好的代码，甚至提供最好的编码员指导(说实话，您的热门程序员是否实际上编写了可读的代码？)一旦您可以说服经验不足的员工说他们没有了解某事-您不在。一些热门照片会大吹大＆，但实际上最好的照片会考虑他们写的内容，并实际更改变量名称或布局-甚至可能添加注释。

第四项目使用强加于"随机"审查的方案，并且尚未引入技术线索(团队破裂？)

您描述的两种做法是形式化方法。它们不适用于所有个性和团体。

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

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

从结对编??程移至github上的PR评论后进行的比较分析。

重点是逐步列出我们的团队现在在PR审查过程中要遵循的内容。