同行评议或结对编程,或两者兼而有之?[闭门]

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

当我们在门口检查自我时,我喜欢同行评议。(这包括我的!)在这个世界上,时间是有限的,你能学到的东西和能做的事情也是有限的。通过良好的同行评议,你可以扩大你的知识面,在更短的时间内完成更多的工作。当这些东西退化为语法检查时,问题就出现了。

因此,我有一些规则。我不会对任何我们可以自动化的东西进行同行评审。运行拼写检查和代码美化程序。如果你有类似FXCop的东西,运行它,按照它说的去做,或者有一个很好的理由来解释为什么你没有。然后我们可以看看代码是如何组合在一起的,它是如何工作的,以及我们可以做些什么来改进它。通过这种方式,你可以从不同的角度看待如何解决问题以及为什么有人会这样想。有时,另一种方法并不真的更好,有时,新的解决方案非常棒,您将在以后的编程生活中使用它。 一旦审查完成,就这样,我不会用它作为反对你的例子。你可以从中学到什么。我不会用恐惧或威胁来对付你,你是个聪明人,我会让你表现出来的。

我们试图确保没有代码在不经过至少另一双眼睛的情况下进入生产环境。

此外,在我们有足够的可用人员的项目中(当任务大小合适时),我们尝试配对编程。
我必须说,我们确实看到了这方面的优势。首先,这是指导团队中初级开发人员的一种很好的方式——当您查看他们的代码时,您可以向他们展示哪些工作可以做得更好,当与他们配对时,他们可以看到更好的工作方式,有经验的人如何思考,甚至如何更好地使用IDE。
此外,它还可以让整个团队保持同步,以了解代码的外观。
此外,它只是增加了每个人的快乐和个人发展——一个能够谈论和推理代码的团队是一个更好的团队,一个不断学习和分享的团队。

一些需要注意的事情:

• 不要让人们在小任务上结对,通常会浪费时间
• 记得时不时地重新排列这对

同行评议应该是 强制性的 .

您可以阅读并找到许多文章和书籍,讨论在不同规模的团队中实现这一点的不同方法,但您似乎在询问经验。

创意人员通常聚在一起展示他们目前从事的绘画、设计和艺术家,以帮助激发灵感。实际上,灵感应该是你希望在评论中培养的主导概念。其次,人们只是自然而然地注意到他们的开发伙伴所做的他们以前没有注意到的事情。哦,哇,那么你用一行代码就做到了?凉的让开发人员对他们所做的事情、他们正在做的事情以及他们如何去做得到启发和激励,这将比使用同行评议来确定优序和排名更能带来回报。

最后,是实际审查部分,但这是一个不可避免的事实。你的优秀开发人员会看到糟糕的代码,在经过足够多的审查后,糟糕的代码编写人员要么升级,要么忘记它。

差点忘了接触结对编程。这更难设置。显然,你不能让两个较弱的程序员一起工作,或者你也可以用一百万台打字机安排一百万只猴子。试着让一个更强的人和一个更弱的人在一起,并私下给他们提供激励。较弱的人应该知道改进是可以得到回报的(如果他们需要这样的激励),而较强的程序员应该知道真正的领导者从良好的导师开始。确保较弱的开发人员正在键入。反之亦然,否则将成为演示文稿和“ 打哈欠 “有些人可能不会从经验中获得任何东西。

我做过很多敏捷指导,为了帮助人们克服结对编程的“耻辱”,我们称之为“实时代码和设计评审”。用这些术语来说,人们似乎能更好地理解这个概念。

从那以后,我参与了大量的离线代码评审。

任何工作审查的好处都应该是让每个人都能写出更好的代码,甚至给最好的程序员提供指导(老实说,你的热门程序员真的能写出可读的代码吗?),一旦你能说服经验不足的员工说他们不懂什么,你就走了。一些热门人物会怒不可遏;但是真正最好的人会考虑他们写了什么,并实际更改变量名或布局,甚至可能添加注释。

第四个项目使用“随机时间”审查的强制方案,但技术负责人尚未加入其中(团队破裂?)

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

是的,我们公司使用同行代码审查。我们将其作为间接评审进行,并邀请团队测试人员参加会议,以更好地了解更改。

正如一些研究已经证明的那样,代码审查有一定的好处。对于我们公司来说,很明显,代码质量随着支持调用数量的减少而提高,报告的bug数量也随之减少。注意:这里的一些好处是实现Scrum和放弃瀑布的结果。下面是关于Scrum的更多信息。

代码审查的好处是,当它应用于结构和编码标准时,它可以是一个更稳定的产品,更易于维护的代码,并且它允许开发人员更多地关注新特性,而不是消防bug和其他生产问题。如果代码评审是正确的,那么就没有任何缺点。更多关于正确的方式如下。

并列争球 使用Scrum方法的好处之一是开发周期(sprint)很短。sprint的时间框架由最适合您的组织的内容决定,需要一些尝试和错误,但实际上不应该超过四周的迭代。其好处是,它要求开发人员每天进行沟通,并在项目早期沟通问题。这最初是由我们的开发部门采用的,随着scrum的好处的深远影响,它已经扩展到我们公司的各个领域。有关详细信息,请参阅: http://en.wikipedia.org/wiki/SCRUM http://www.scrumalliance.org/ . 随着开发迭代次数的减少,代码评审过程评审较小的代码片段,使得评审比数小时或数天的正式评审更有可能发现问题。

只需对间接审查作一点澄清;这些可以在这里通过远程桌面进行。然而,它们不应该仅限于开发者。我们通常邀请整个scrum团队,每个团队由两名开发人员、一名测试人员、一名文档人员和产品负责人组成。所有非开发人员都在那里,以便更好地了解正在进行的更改或新功能。他们可以自由提问或提供输入,但不能做出编码决策或评论。这是有效的,因为某些问题可能会改变项目的方向,因为最初的需求可能错过了一个场景,但这就是敏捷的全部,改变。

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

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

https://blog.mavenhive.in/pair-programming-vs-code-reviews-79f0f1bf926