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

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

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

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

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

解决方案

回答

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

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

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

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

最后，是实际的审查部分，但这是不可避免的事实。优秀开发人员将看到不良代码，并在对其进行了充分的审查之后，发现不良代码可能需要逐步升级或者忘记它的时间。

如果我们保持积极的态度并有条理地组织活动，那通常是很棒的经历。

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

回答

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

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

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

回答

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

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

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

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

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

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

尝试我们认为团队可以实际做的事情，然后查看是否可以改进。

一旦我们对代码有额外的关注，我们将不愿回头

回答

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

回答

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

需要注意的一些事项：

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

回答

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

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

？代码审查的好处是可以使产品更稳定，代码更易于维护，因为它适用于结构和编码标准，并且使开发人员可以将更多的精力放在新功能上，而不是消防漏洞和其他生产问题上。如果正确进行代码审查，确实不会有任何弊端。下面以正确的方式提供更多信息。

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

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

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

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