结对编程_结对编程：使其工作的好处，技巧和建议

爱被打了一巴掌 2022-12-03 01:43 191阅读 0赞

结对编程

**Pair Programming — a pair that’s greater than the sum of its parts. You may have heard about pair programming and wondered whether it was worth trying in your workplace. On the surface it sounds simple, but two developers sitting together are not all that it takes to achieve productive pairing.**

**配对编程-一对大于其总和。** **您可能听说过结对编程，并且想知道在工作场所是否值得尝试。** **从表面上看，这听起来很简单，但是两个开发人员坐在一起并不是实现高效配对所需要的全部。**

Logistical and personal hurdles such as scheduling, tool choices, and distractions can stop you from getting the most out of pairing. But the potential advantages can make it worth the trouble of recognizing and surmounting these challenges.

诸如计划，工具选择和分散注意力等后勤和个人障碍可能会使您无法充分利用配对。 但是潜在的优势可能使您值得去认识并克服这些挑战。

## 为什么配对？ **(**Why Pair?**)** ##

How could it be more productive to take two programmers who were previously working on separate projects and have them work together on a single project? Won’t everything take twice as long? To an outsider the idea of pairing may sound counterproductive at first, but the advantages become apparent when you start to think about why we code and what we’re trying to accomplish.

雇用两个以前在不同项目中工作的程序员，然后让他们在一个项目中一起工作，会更有效率吗？ 不会花所有时间的两倍吗？ 对于局外人来说，配对的想法乍看起来可能适得其反，但是当您开始思考我们为什么编写代码以及要完成的工作时，优势就变得显而易见。

Programming is not about churning out the most lines of code in the shortest amount of time, or even delivering the most features within increasingly tight deadlines. You can have engineers working around the clock pushing new features into production, but how productive are they really if those features are cranked out by individuals working in isolation according to their own unique understanding of the overall architecture? The resulting code is likely to be riddled with technical debt such as hidden bugs, performance issues, idiosyncratic syntax, and inefficient designs that may not use resources efficiently and may make it that much more difficult and time consuming to modify the code when one of those flaws surfaces.

编程并不是要在最短的时间内生产出最多的代码，甚至不是在越来越紧迫的期限内交付最多的功能。 您可以让工程师昼夜不停地将新功能投入生产，但是如果这些功能是由个人根据自己对整体体系结构的独特理解而单独开发出来的，那么它们真的有多大的生产力？ 产生的代码可能会充满技术负担，例如隐藏的错误，性能问题，特质的语法以及效率低下的设计，这些设计可能无法有效利用资源，并且使修改代码变得更加困难和耗时，而其中之一是缺陷表面。

You need your code to be meaningful and well written so that it works together seamlessly and can be modified easily. You need it to encapsulate the desired functionality so that your end product behaves properly and performs as expected. You need it to be resilient so it can withstand organizational changes that are a natural part of working together, as well as environmental changes and new customer expectations that may make today’s workable solution obsolete without much warning.

您需要代码有意义并且编写得当，以便它们无缝地协同工作并且可以轻松地进行修改。 您需要它来封装所需的功能，以便最终产品正常运行并按预期运行。 您需要使它具有弹性，以便它可以承受自然而然地发生的组织变更，环境变更和新客户期望，这些可能会使当今可行的解决方案过时而又没有太多警告。

In order to make that possible, developers need to be able to agree about fundamental requirements clearly, get up to speed quickly with whatever new or established technologies may be required, and focus without interruption to test out creative solutions and develop a product that’s worth putting in front of the customer.

为了使之成为可能，开发人员需要能够清楚地同意基本要求，Swift掌握可能需要的任何新技术或既有技术，并专注于不间断地测试创意解决方案并开发值得投入的产品在客户面前。

These are the real-world challenges that pair programming helps to address. When two developers work together in a pair, the quality of the code they produce improves along with their shared understanding of how it works. This makes it easier for the next person who reads the code to pick it up and modify it when necessary, and it reduces the danger that the only person on the team who knows how part of the code works may win the lottery and leave the team, taking that precious knowledge with them.

这些是结对编程有助于解决的现实世界中的挑战。 当两个开发人员一起工作时，他们产生的代码质量以及对代码工作方式的共同理解将得到改善。 这使下一个阅读代码的人更容易在需要时进行拾取和修改，并且减少了团队中唯一知道部分代码工作原理的人可能中奖并离开团队的危险。与他们一起获得宝贵的知识。

The time cost in [mythical work hours][] is nowhere near the 50% that may seem intuitive if you tried to to equate the intricate art of coding with repetitive assembly line work. Some [empirical studies][] have concluded that pair programming might result in about a 15% increase in the time it takes two programmers to accomplish the same tasks had they been working alone, but the resulting code will also be of much higher quality, with about 15% fewer observable defects to fix. Combine this with the shared ownership, deeper engagement, and faster problem solving that comes from having more than one mind engaged in solving a problem, and it’s clear why pair programming is a popular approach.

如果您试图将复杂的编码艺术与重复的装配线工作等同起来，那么[神话般的工作时间中][mythical work hours]的时间成本将远不及50％的直观成本。 一些[经验研究][empirical studies]得出的结论是，成对编程可能会使两个程序员(如果他们一个人工作)完成相同的任务所需的时间增加大约15％，但是结果代码的质量也要高得多，大约为15％更少的可观察到的缺陷可以解决。 结合使用共享所有权，更深入的参与和更快的问题解决能力，这要归功于一个以上的头脑来解决问题，这很清楚为什么配对编程是一种流行的方法。

## 配对到底是什么？ **(**What Exactly is Pairing?**)** ##

So what does it take for two developers working together to achieve the productivity and quality improvements that come from pairing? It’s mostly a matter of learning how to work collaboratively, which is not necessarily the way most of us learned to code.

那么，两个开发人员一起工作以实现配对带来的生产率和质量改善又需要什么呢？ 这主要是学习如何协同工作的问题，这不一定是我们大多数人学习编码的方式。

By definition, pair programming doesn’t start until you have two people working together on one computer. But how does that work in practice?

根据定义，只有在两个人在一台计算机上一起工作时，配对编程才开始。 但是，这在实践中如何运作？

### 两个人…… **(**Two People …**)** ###

The fundamental element of pair programming is working together with your pair. When a task is accepted, it needs to be shared between both of the people working on it, and they both need to be fully engaged in the task while they’re pairing on it. That means that they both need to understand the requirements the same way, and work together to come to a shared understanding of how they want to go about meeting them.

结对编程的基本要素是与您的结对一起工作。 接受任务后，需要在两个工作人员之间共享该任务，并且他们都需要在配对时充分参与该任务。 这意味着他们都需要以相同的方式理解需求，并共同努力以达成对如何满足这些需求的共识。

Pairing helps people get better at verbalizing their ideas and expectations. The implicit understanding you have in your head when you’re working alone needs to be communicated so both you and your pair know you’re on the same page. Getting as explicit as possible about the work and the approach up front will help make the pairing experience much more agreeable. Pairing involves a lot of talking, as that’s the best way to keep two minds actively engaged in the problem at the same time.

配对有助于人们更好地表达自己的想法和期望。 需要传达您独自工作时头脑中的隐含理解，以便您和您的伴侣都知道您在同一个页面上。 尽可能明确地了解工作和方法将有助于使配对体验更加令人满意。 配对涉及很多话题，因为这是让两个人同时积极参与问题的最佳方法。

For this reason, pairing is often associated with agile story writing, in which requirements for a feature are defined in consistent, plain language that can be understood equally well by Product and Engineering people with little room for ambiguity. Often pairs will ask for stories to be spelled out in [Gherkin][], which is a way of using common, non-technical phrases that are easy to translate into [automated tests][], so the pair can verify and demonstrate that each feature works as expected.

由于这个原因，配对通常与敏捷的故事写作相关联，在敏捷的故事写作中，功能要求以一致的普通语言定义，产品和工程人员可以毫不歧义地理解它们。 通常，两人会要求用[Gherkin][]拼写故事，这是一种使用常见的非技术性短语的方式，这些短语很容易转化为[自动化测试][automated tests] ，因此，这对夫妇可以验证并证明每个功能都能按预期工作。

Writing in Gherkin means taking a feature and breaking it down into a simple **story** about a customer who wants something that this feature will deliver:

用Gherkin编写意味着将一项功能分解为一个简单的**故事** ，该**故事**讲述了一个客户想要该功能将提供的功能：

As <a customer of the product>
    I want <something desirable>
    So that <I can achieve a specific goal>

Then all the **acceptance criteria** are written out in a consistent syntax, defining the anticipated permutations and scenarios associated with that story:

然后，以一致的语法写出所有**接受标准** ，定义与该故事相关的预期排列和方案：

Given <a customer in a particular state>
    When <something specific happens>
    Then <there is a specific outcome>
    
    Given <a customer in a particular state>
    When <something different happens>
    Then <there is a different specific outcome>
    
    etc.

Of course, it’s not mandatory to use this exact phrasing, but if the requirements of a feature can’t be expressed in this minimalist way, it’s possible that the expectations are ambiguous. That’s a potential red flag that’s easier for a pair of programmers to spot when they start to discuss what’s needed.

当然，使用此精确措词不是强制性的，但是如果不能以这种最低限度的方式来表达功能的要求，则期望可能会模棱两可。 这是一个潜在的危险信号，当一对程序员开始讨论需要的东西时，他们很容易发现。

As soon as a pair accepts a story to work on, they should be able to define how they will know they are done and how they’re going to prove it. From there, they can start to figure out together how best to approach the job.

一旦一对人接受了一个故事，他们就应该能够定义他们将如何知道自己的完成以及如何证明这一点。 从那里，他们可以开始一起找出如何最好地完成工作。

In fact, the pair working on a feature should know enough up front that they could start by writing an automated test based on the first acceptance criterion *before writing any code*, making sure the new test fails, and then writing just enough code to make that test pass before refactoring and then starting on the next acceptance criterion. This approach is known as [behavior-driven development][], and while it’s not part of the definition of pair programming, it harmonizes beautifully, along with [test-driven development][].

实际上，从事某项功能的工作人员应该*事先*了解足够的知识，以使他们可以*在编写任何代码之前*先根据第一个接受标准编写一个自动化测试，以确保新测试失败，然后再编写足够的代码以使他们开始工作。在重构之前先测试通过，然后从下一个验收标准开始。 这种方法被称为[行为驱动的开发][behavior-driven development] ，虽然它不是结对编程定义的一部分，但它与[测试驱动的开发][test-driven development]完美地[融为一体][test-driven development] 。

### 合作 … **(**Working Together …**)** ###

When you have two or more people trying to work together, the first thing they need to do is agree on a work schedule. It’s not really pairing if two developers aren’t working together at the same time. Because of this, it’s essential that the developers who plan to work together coordinate their schedules and make sure they both agree to a time and place where they will work.

当您有两个或两个以上的人试图一起工作时，他们要做的第一件事就是在工作时间表上达成共识。 如果两个开发人员不能同时工作，那并不是真正的配对。 因此，计划一起工作的开发人员必须协调他们的日程安排，并确保他们双方都同意他们将工作的时间和地点，这一点至关重要。

One mistake I’ve seen pairs make is trying to maximize the time they work together as a pair by scheduling a full eight hours together, and sometimes trying to work together beyond that. Pairing is intensive work that requires a heightened level of focus and participation. It’s very taxing to try to pair for more than five or six hours in a day, and even that might be stretching it for even the most resilient of us. When setting up a pairing schedule, try to agree on a fixed and limited time that will fit within a typical eight-hour work day, leaving time for lunch, email, personal tasks, etc. Those personal tasks are essential to our work day, but they’re also distractions that shouldn’t be attempted during a pairing session.

我见过的一对人犯的一个错误是，试图通过安排整整八个小时的时间来最大化他们作为一对的工作时间，有时甚至尝试一起工作。 配对是一项繁重的工作，需要更高的关注度和参与度。 每天尝试配对超过五六个小时是非常麻烦的，即使对于我们最有弹性的人来说，这样做也可能会延长。 设定配对时间表时，请尝试约定一个固定且有限的时间，以适合典型的八小时工作日，留出时间吃午饭，电子邮件，个人任务等。这些个人任务对于我们的工作日至关重要，但它们也令人分心，在配对过程中不应该尝试。

It can also be socially awkward to remind your pair when the agreed pairing time has come to an end. For that reason, it can be a good idea to set an alarm that will break the news to both of you without putting the burden on one or the other.

当约定的配对时间结束时，提醒您的配对在社交上也很尴尬。 出于这个原因，最好设置一个警报，以在不增加彼此负担的情况下向您俩发布新闻。

Skill level is another area where pairs can have trouble. It’s a fair assumption that, no matter what you’re working on, the person you’re working with has a different background, experience, and comfort with the topic. Recognizing that up front is important, so neither of you will feel the need to try to hide that fact. One of the benefits of pairing is that working together naturally brings up the skills of anyone learning something new, whether that something is a programming language or a communication style.

技能水平是配对可能遇到麻烦的另一个领域。 一个公平的假设是，无论您从事什么工作，与您一起工作的人都有不同的背景，经验和对该主题的适应程度。 预先意识到这一点很重要，因此你们俩都不会觉得有必要隐瞒这一事实。 配对的好处之一是，自然地合作可以提高任何学习新知识的人的技能，无论这些知识是编程语言还是交流风格。

Be gracious if you feel you’re more skilled than your pair. Treat them the way you’d want to be treated as you learned something new. And remember that the point is not only to get the work done, but to make sure that both of you have sufficient knowledge and ownership of the end result.

如果您觉得自己比同龄人更熟练，请客气。 当您学到新东西时，以您希望的方式对待他们。 请记住，这不仅是要完成工作，而且是要确保你们俩都对最终结果有足够的知识和所有权。

To that end, it’s vital that each programmer have the opportunity to sit at the keyboard and drive while the other observes and navigates through the code. The concept of taking turns may be new to anyone whose exclusive experience as a programmer has been solo work, so there will be a learning curve as you adapt to verbalizing your intentions when navigating, or carrying out someone else’s ideas when driving.

为此，至关重要的是，每个程序员都有机会坐在键盘上驱动，而另一个则观察并浏览代码。 对于那些曾经独自从事过程序员的人来说，轮换的概念可能是陌生的，因此当您适应在导航时表达自己的意图，或者在开车时执行他人的想法时，学习弯道将是一个学习曲线。

A programmer new to pairing but comfortable with the task at hand can easily get into a pattern of holding onto the driver role for as long as possible. Similarly, if you’re not driving at the keyboard and you’re not all that familiar with the code, it’s easy to find your mind wandering back to your phone, your email, and your other tasks. When that happens, you end up with one person coding alone and the other person sitting in the same room scrolling through social media.

结对但对当前任务不熟悉的程序员可以轻松地尽可能长时间地担任驾驶员角色。 同样，如果您不使用键盘操作并且对代码不那么熟悉，那么很容易发现您的想法又回到了手机，电子邮件和其他任务上。 发生这种情况时，您最终将只有一个人独自编码，而另一个人坐在同一个房间中，通过社交媒体滚动。

One of the clues that a pair might be having trouble taking turns is silence. Pairing is a noisy process, involving a lot of questions, feedback, discussion, and collaboration. When a pair finds themselves going for more than a minute or two without saying a word, it’s likely the pairing has stopped.

一对人可能难以轮流的线索之一就是沉默。 配对是一个嘈杂的过程，涉及许多问题，反馈，讨论和协作。 当一对发现自己过去一两分钟没有说话时，很可能配对已经停止。

One useful technique that can keep pairs from falling into this antipattern is to use a [Pomodoro timer][]. These timers will keep a running countdown of the seconds as you work in 25-minute increments, and then tell you to take a break for five minutes. By switching roles between the driver and the navigator during these breaks, a pair can avoid lapsing into extended sessions with just one driver.

一种可以防止线对陷入这种反模式的有用技术是使用[Pomodoro计时器][Pomodoro timer] 。 当您以25分钟为增量工作时，这些计时器将使秒数连续倒计时，然后告诉您休息五分钟。 通过在这些休息时间期间在驱动程序和导航器之间切换角色，一对可以避免仅由一个驱动程序陷入扩展会话。

### 在一台计算机上… **(**On One Computer …**)** ###

Pairing only works when two people dedicate their full attention to a single computer. It’s better to avoid the distraction of having two (or more) active screens going during a pairing session. Even if one person just wants to look up some relevant code examples or check on the status of a background process, it’s better to do that on the one shared computer. If it’s a search, both developers can see how the search is constructed and what potential results come up. If it’s a status update, neither developer needs to be left behind.

只有两个人全神贯注于一台计算机时，配对才有效。 最好避免在配对过程中让两个(或多个)活动屏幕分散注意力。 即使一个人只想查找一些相关的代码示例或检查后台进程的状态，也最好在一台共享计算机上执行此操作。 如果是搜索，那么两个开发人员都可以看到搜索的结构以及潜在的结果。 如果是状态更新，则无需任何开发人员。

So in any pair, both developers must be able to see the screen they are working on together clearly. One of the essential tools for pairing is a monitor big enough that both developers can see what’s being written clearly. Depending on the circumstances, this can be accomplished with a shared laptop if you don’t mind huddling together and you use a large enough font with adequate contrast. A better solution is a larger desktop or wall-mounted monitor where the code can be displayed and viewed together more comfortably.

因此，在任何一对中，两个开发人员都必须能够清楚地看到他们一起工作的屏幕。 配对的基本工具之一是监视器，监视器的大小足以让两个开发人员都能清楚地看到正在编写的内容。 根据情况，如果您不介意挤在一起，并且使用足够大且具有足够对比度的字体，则可以使用共享笔记本电脑完成此操作。 更好的解决方案是使用大型台式或壁挂式显示器，在其中可以更舒适地一起显示和查看代码。

Remote pairing is a very viable option these days. There are a number of great solutions ranging from [Slack][] or [Zoom][] tools to full-blown [integrated development environments and text processors][] that support screen sharing, conference calling, or both, allowing two people on opposite sides of the desk or opposite sides of the world to work together. Even if you’re at the next seat in an open office, screen sharing can make it easier for both of you to see and interact with the code on the screen more comfortably. (I just encourage you to stay focused and resist the urge to bring up your email in a separate window while you’re pairing remotely. It’s disrespectful, it will be obvious to the person you’re pairing with, and your distraction will make you miss out on opportunities to learn together and produce quality results.)

如今，远程配对是一个非常可行的选择。 从[Slack][]或[Zoom][]工具到成熟的[集成开发环境以及][integrated development environments and text processors]支持屏幕共享，电话会议或同时支持这两种功能的[文本处理器][integrated development environments and text processors] ，有许多种出色的解决方案，它们可以使两个人坐在办公桌的相对侧或世界的相对侧。一起工作。 即使您在开放式办公室的下一个座位上，屏幕共享也可以使您更轻松地在屏幕上查看代码并与之交互。 (我只是鼓励您保持专注，并避免在进行远程配对时在单独的窗口中显示电子邮件的冲动。这是不尊重他人的，对与之配对的人来说很明显，而分心会使您错失了共同学习并产生高质量成果的机会。)

If a colocated pair is sharing a single machine, they’ll need to come to some agreements about the configuration of their shared computers, keyboards, mouses, etc. That ergonomic keyboard with all the custom hardware macros might not be the best choice for sharing. But if you don’t mind using the same laptop or keyboard and mouse, swapping roles from navigator to driver in a pair might be as simple as switching places.

如果同一地点的一对共享一台计算机，则他们需要就共享计算机，键盘，鼠标等的配置达成一些协议。带有所有自定义硬件宏的符合人体工程学的键盘可能不是共享的最佳选择。 但是，如果您不介意使用同一台笔记本电脑或键盘和鼠标，则将导航器中的角色互换为驱动器中的角色可能就像切换位置一样简单。

A popular and very robust solution is to make active use of a version control system like Git. Commit your code frequently to a shared repository so each developer can pull the latest version and work on their own device when they switch roles. Using version control to handle swapping in pairs has the added advantage of creating a more detailed history of code changes for future logging and potential rollbacks. If the Git logs get too cluttered, it’s always possible to go back and squash those extra commits into a single, more meaningful one before doing a pull request.

一个流行且非常强大的解决方案是积极使用诸如Git之类的版本控制系统。 经常将您的代码提交到共享存储库，以便每个开发人员可以在切换角色时提取最新版本并在自己的设备上工作。 使用版本控制来成对处理交换具有额外的优势，即创建更详细的代码更改历史记录以用于将来的日志记录和潜在的回滚。 如果Git日志过于混乱，那么在执行拉取请求之前，总是有可能将这些多余的提交压缩成一个更有意义的单个提交。

At a higher level, once you start pairing with another developer, you’re going to notice some differences in the ways you each approach your tasks. One of you might know some fancy keyboard shortcuts, have some special aliases for common shell commands, or prefer to use a specific IDE because of its unique features. In terms of the code itself, you may also each have a different implicit understanding about how variables are named, how to structure a commit message, when to use comments, etc.

在更高的层次上，一旦开始与另一位开发人员配对，您将注意到每种处理任务的方式都有一些差异。 你们当中的一个可能知道一些精美的键盘快捷键，一些常见的Shell命令具有特殊的别名，或者由于其独特的功能而倾向于使用特定的IDE。 就代码本身而言，您可能还分别对变量如何命名，如何构造提交消息，何时使用注释等有不同的隐含理解。

Pairing is an opportunity to make these unconscious variations in technique visible so everyone can benefit from the hidden wealth of experience and knowledge about how we code more effectively.

配对是使这些无意识的技术变化可见的机会，因此每个人都可以从隐藏的丰富经验和知识中受益，这些经验和知识涉及我们如何更有效地编码。

## 如何开始配对 **(**How to Start Pairing**)** ##

There’s often a period of adjustment while building the muscle memory and learning to express ideas out loud that were once just thoughts in the back of your head. It’s also necessary to establish workable logistics to allow two people to work together, which might mean making adjustments in terms of schedules, locations, and equipment. And when you’ve got that working, you might try expanding the process to the whole team with enhancements such as [mob programing][] for groups, or [promiscuous pairing][] to give everyone on the team a chance to pair on all of the team’s stories.

在建立肌肉记忆力并学会大声表达曾经只是想法的想法时，通常需要一段时间的调整。 建立可行的物流体系以使两个人一起工作也很有必要，这可能意味着要在时间表，位置和设备方面进行调整。 并且，当您完成工作后，您可以尝试通过增强功能(例如为小组进行[暴民编程][mob programing]或[混杂配对)][promiscuous pairing]将流程扩展到整个团队，从而使团队中的每个人都有机会结识团队中的所有故事。

Putting in the effort to get through the learning stages usually pays off in significant improvements, both for the quality of the code and for the happiness and sustainability of the people who create it. And if your entire team or organization adopts pairing, the learning curve will become even easier for new people, improving the onboarding process and helping everyone be more productive.

付出努力来学习阶段通常会带来重大的改进，无论是代码的质量还是代码编写者的幸福感和可持续性。 而且，如果您的整个团队或组织采用配对，那么新人的学习曲线将变得更加轻松，从而改善了入职流程并帮助每个人提高了工作效率。

> 翻译自: [https://www.sitepoint.com/pair-programming-guide/][https_www.sitepoint.com_pair-programming-guide]

结对编程

[mythical work hours]: https://en.wikipedia.org/wiki/The_Mythical_Man-Month
[empirical studies]: https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
[Gherkin]: https://github.com/cucumber/cucumber/wiki/Gherkin
[automated tests]: https://cucumber.io/
[behavior-driven development]: https://www.sitepoint.com/bdd-javascript-cucumber-gherkin/
[test-driven development]: https://www.sitepoint.com/learning-javascript-test-driven-development-by-example/
[Pomodoro timer]: https://www.sitepoint.com/the-pomodoro-technique-time-management/
[Slack]: https://slack.com/
[Zoom]: https://zoom.us/
[integrated development environments and text processors]: https://www.sitepoint.com/collaborative-coding-tools-for-remote-pair-programming/
[mob programing]: https://mobprogramming.org/mob-programming-basics/
[promiscuous pairing]: https://agilefaq.wordpress.com/2007/11/03/what-is-promiscuous-pairing/
[https_www.sitepoint.com_pair-programming-guide]: https://www.sitepoint.com/pair-programming-guide/