12!配对_将编程与救援再次配对！

12!配对

前段时间，我写了成对编程如何帮助保持高质量的代码 。 但这还不是全部！

今天，我想解释一下为什么您应该练习配对编程以使用新的木工。 它使整个过程更快，更高效。

新加入者加入团队

在我从事的大多数项目中，我们假设一个新加入的员工在头三个月中会对团队的生产力产生负面影响。 您必须帮助他们在新工作中安顿下来并帮助他们设置一切。 您必须在项目和工具的配置中共享所有这些小技巧。

会有问题。 他们将期待每个人的答案。 他们将带来想法，建议，评论。 这些日子里会有很多“为什么”。 那很好！ 这证实了让他们加入团队是一个不错的选择。

但是那是三个月！ 三个漫长而辛苦的月份。 对于双方–团队和新加入者。 而更大的项目，则时间越长越耗时。 在我的职业生涯中，我看到了一些加入新入职员工的方法。 让我挑战那些我发现的最普通的人。

让我们解决一个错误

这样做的目的是通过研究多汁的bug，为新加入者提供学习应用程序的机会。 他们将有机会看到和学习​​一切，不是吗？

但是，即使您真的相信它可行，这种方法也会存在一些问题。

新加入者既不了解应用程序的业务领域，也不了解其技术方面。 这很明显，但是与引入新功能相比，这种情况下知识的缺乏使事情变得更加困难。 显然，他们会问，但是第一步通常是尝试自己理解所有内容。 后续步骤将他们引向Google。 然后，在远端，会有问题。 因此，这将需要很多时间。

您还必须记住，解决错误时，它们有可能落在一些被遗忘的地方。 他们将看到没人能理解的代码。 他们会问的问题再也没人能回答。 找到它们将需要一些努力。

还有什么要记住的重要事项？ 一个新加入的木匠可能最终陷入困境，不知道去哪里，因为代码丢失了，成功的机会很小。 听起来不那么有动力吗？ 你怎么看？

遍历代码

“只需检查一下代码，然后问任意多个问题即可。 您可以从这里，这里和这里开始。”
–我过去自己说过几次。 有什么影响？ 数小时的谷歌搜索和大量问题。 从表面上看，它甚至看起来还不错，但问题是新加入的木匠询问并学习了几乎从未触及过的事物/模块/地方。

入职的目标是将新应用程序更改为可以使用的应用程序。 不要用所有可能的细节来填补新入职员工的头。

知识共享会议/文档

如果有您的应用程序文档，那很好。 如果您正在组织知识共享会议，那就太好了。 但是它只能作为其他活动的实现，而不能替代。

即使您提供了详细的会话并获得了丰富且最新的文档，也无法记住所有事情。 即使有人渴望学习，他们记住的几率也很小。

刚开始工作

至少新加入者知道他们在做重要的事情，用户正在等待的事情。 如有疑问，团队中的大多数人都将能够提供答案-他们已经在相同的环境中。

只有一个“但是” –连续的中断。 会有问题，你们中的一个必须提供答案或显示正确的方向。 它对新入职人员和您的工作都产生了负面影响。 为什么？

问题越多，新入职者对下一个询问的感觉就越不舒服。 他们将越来越努力地自己寻找答案。

另一方面，如果有问题，您将不得不停止， 您必须更改上下文，这有一定的代价 。

这会让你们俩都慢下来。

配对编程进行救援！

一段时间以来，我认为让新的入职者开始研究当前的交付成果是最好的选择。 然而，中断仍然是问题所在。 在入职期间，问题是一个常数，您无法消除它。

您能做什么呢？ 如果您必须打断他人的工作来询问他们，则可以消除它们带来的负面影响。 如果配对，则可以完全消除这些干扰！ 您正在做同一件事，所以您处于同一上下文中。 问题是在同一上下文中！

此外，通过查看编写代码的方式，新加入者将更熟悉团队中实践的技术。 通过查看它们，您可以共享反馈而无需等待问题。

双赢的局面，不是吗？

下次，当有新人加入您的团队时，我鼓励您尝试与他们配对。 我敢肯定，您会发现它是加入新开发人员的高效快捷方式！ 祝好运！

翻译自: https://www.javacodegeeks.com/2017/06/pair-programming-rescue-2.html

12!配对