取消远程ssh的key配对_配对程序的不同方式，即使您是远程的

取消远程ssh的key配对

Pair programming has been a point of contention for a long time, with much of the focus on whether one should pair program or not. However, this article is not about whether you should pair or not — but rather, about what styles of pair programming you can consider adopting. Undoubtedly, with the rise of remote working this year, pair programming has been turned on its head in some workplaces, with many finding it difficult due to limitations on video conferencing. With this in mind, let’s do a deep dive into the different formats of pairing.

长期以来，配对编程一直是争论的焦点，其中很多重点放在是否应该配对编程上。 但是，本文不是关于是否应该配对，而是关于可以考虑采用的配对编程样式。 毫无疑问，随着今年远程工作的兴起，结对编程已在某些工作场所掀起了轩然大波，许多人发现由于视频会议的限制而变得困难。 考虑到这一点，让我们深入研究配对的不同格式。

驾驶员导航 (Driver-Navigator)

Driver-Navigator style is very common among developers who pair program. The format is as follows:

Driver-Navigator样式在配对程序的开发人员中非常普遍。 格式如下：

• One person “navigates,” that is, think of them like the person holding the map in the car. They are constantly telling the driver what to type to achieve a certain goal.
  一个人“导航”，也就是说，就像在车里拿着地图的人那样思考他们。 他们不断告诉驾驶员要实现某个目标的键入内容。
• The second person “drives.” They are the driver, and they are executing instructions that the navigator is telling them.
  第二个人“开车”。 他们是驾驶员，他们正在执行导航员告诉他们的指令。

An extra technique you can apply to this is the Pomodoro technique. I like to do 30-minute blocks: the first 25 minutes follows the driver-navigator pattern and then there is a 5-minute break. After the break, the driver and the navigator swap roles.

您可以应用的另一种技巧是番茄 技术。 我喜欢做30分钟的封锁：前25分钟遵循驾驶员-导航员的模式，然后有5分钟的休息时间。 休息后，驱动程序和导航员互换角色。

Another topic of discussion (one you could discuss with your pair) is whether or not the driver should blindly follow the navigator’s instructions even if they know said instructions are wrong. One argument I’ve heard for this is that the driver can concentrate on syntax and writing code and the navigator can fully concentrate on the logic and problem-solving side. In pairing scenarios where one person is more dominant than the other, it could provide the less dominant person a chance to steer. However, given that one of the main benefits of pairing is that you get to share ideas and different approaches, I personally tend to prefer having the driver rebuke the navigator’s instructions if they think it’s “going the wrong way.” After all, doesn’t this happen on a real road trip?

讨论的另一主题(您可以与您的同伴讨论)是驾驶员是否应该盲目地遵循导航员的指示，即使他们知道上述指示是错误的。 我听到的一个论点是，驱动程序可以专注于语法和编写代码，而导航器可以完全专注于逻辑和解决问题的方面。 在一个人比另一个人更具统治力的配对场景中，它可以为不那么统治力的人提供操纵的机会。 但是，考虑到配对的主要好处之一是您可以共享想法和不同的方法，所以我个人倾向于选择让驾驶员斥责导航员的指示，如果他们认为这是“走错了路”。 毕竟，这不是在真正的公路旅行中发生的吗？

On the topic of remote pairing, this is actually quite simple to achieve. If you’re using Zoom, simply enable remote control for your pair. Make sure you keep track of time — it’s often hard to be rigorous in the navigator-driver format.

关于远程配对，这实际上很容易实现。 如果您使用的是Zoom，只需为您的配对启用远程控制。 确保跟踪时间-在导航器驱动程序格式中通常很难做到严格。

乒乓 (Ping Pong)

Ping pong is something that works especially well with another methodology called test-driven development (TDD). Briefly, TDD is where you write the failing test first, then make the test past with the minimum amount of code, and then do any needed refactoring. With ping pong pair programming, the format is like this:

乒乓球与另一种称为测试驱动开发 (TDD)的方法特别有效。 简而言之，在TDD中，您首先编写失败的测试，然后使用最少的代码量使测试过去，然后进行任何需要的重构。 使用乒乓球对编程时，格式如下：

• The first person writes the failing test. This includes any production code to enable the test to compile.
  第一人称写失败的测试。 这包括使测试能够编译的任何生产代码。
• The second person makes the test pass with the minimal amount of code possible (this is usually how TDD works and of course, like many other practices in software development, is usually up for debate. Use your common sense in this area, whatever works with your pair).
  第二个人使用尽可能少的代码来使测试通过(这通常是TDD的工作方式，当然，像软件开发中的许多其他实践一样，通常也有争议。在这方面使用您的常识，无论使用什么方法，您的一对)。
• Once the previous test passes, the second person also writes the next test.
  一旦上一个测试通过，第二个人也将编写下一个测试。
• The first person then makes that second test pass. And so forth.
  然后，第一个人进行第二次测试通过。 依此类推。

惠而浦 (Whirlpool)

Whirlpool pair programming is something I have not yet seen in a professional capacity. I’ve only experienced this twice — once as a participant in a dojo/kata/workshop, and the second time as the facilitator of the dojo/workshop. It is as its name suggests — a complete whirlpool. The format is:

尚未对Whirlpool对编程进行专业的研究。 我只经历过两次，一次是作为dojo / kata / workshop的参与者，第二次是作为dojo / workshop的主持人。 顾名思义，它是一个完整的漩涡。 格式为：

• Divide your group into pairs
  将您的小组分成几对
• Each pair works on their task/story for 20 minutes in whatever format they would like, such as driver-navigator (again, the length of time and format can be tweaked depending on your group or team)
  每对他们以自己想要的格式(例如驾驶员导航器)处理他们的任务/故事20分钟(同样，时间长度和格式可以根据您的小组或团队进行调整)
• At the end of the ten minutes, one person in each pair “swaps out” and joins another person’s task/story.
  在十分钟的结束时，每对中的一个人“交换”并加入另一个人的任务/故事。

This format is actually quite tricky and requires a laser-like focus from all participants due to the heavy context switching. However, the benefit is that each participant gets a good cross-section of the codebase(s), provided the tasks are independent enough, and I recall one participant in a session I ran comment that it was “shocking how much context (he) gained over the two hours.” I would argue that this format may not necessarily be sustainable depending on your group of engineers, but it makes for a great session particularly if there is a specific goal, such as bug bashing or refactoring.

这种格式实际上非常棘手，由于上下文切换繁重，因此需要所有参与者进行类似激光的聚焦。 但是，这样做的好处是，只要任务足够独立，每个参与者都可以获得良好的代码库横断面，并且我回想起一个会话中的一个参与者，我曾评论说这“震惊了多少上下文(他)”。在两个小时内获得了收益。” 我认为这种格式可能不一定可持续，具体取决于您的工程师团队，但是它使会议非常成功，尤其是在有特定目标(例如bug扑灭或重构)的情况下。

Remote pairing wise, this one proves a little tricky to facilitate and would require some serious zoom-fu. If you’re using Zoom, you could consider using Zoom breakout rooms to split up the team into pairs, and recall them to join the main room after the internal is finished.

从远程配对的角度来看，此选项在使用上有些麻烦，并且需要进行认真的缩放。 如果您使用的是Zoom，则可以考虑使用Zoom分组讨论会议室将团队分成几对，并在内部完成后召回他们加入主会议室。

兰多里 (Randori)

Randori is again something that is quite popular with dojos/katas/workshops, but can also be used in mob programming situations. A possible format for this in workshops is as follows:

Randori再次在dojos / katas / workshop中非常流行，但是也可以用于暴民编程情况。 研讨会中可能的格式如下：

• A pair (driver and navigator) sit at the front of the room. Their screen is displayed on a projector, set up such that everyone in the room can see it clearly.
  一对(驾驶员和导航员)坐在房间的前面。 他们的屏幕显示在投影仪上，其设置使得房间中的每个人都可以清楚看到。
• Pair programming happens as usual (in standard driver-navigator format or ping pong, as an example). Note that the pair are speaking out loud, so the rest of the team can understand their thoughts and ideas. The rest of the people in the room are mostly observers but can make suggestions when necessary.
  配对编程照常进行(例如，以标准的驾驶员导航器格式或乒乓球形式)。 请注意，两人正在大声说话，因此团队中的其他成员都可以理解他们的想法和想法。 房间中的其他人大多是观察员，但在必要时可以提出建议。
• Every ten minutes (this can be adjusted according to the group) the driver retires, the navigator becomes the driver, and another person in the room comes up to become the new navigator.
  驾驶员每隔十分钟(可根据组情况进行调整)退休，导航员成为驾驶员，而房间中的另一个人则成为新的导航员。

This has some amazing benefits to programming, the first being shared context in the team. Everyone knows exactly why each decision was made, leading to less rework later on and raises the bar for quality. The same holds true for if this was for a workshop. The second benefit is a little more nuanced. Using the Randori method could help everyone in the team get a chance to contribute to a mob programming situation.

这对编程有一些惊人的好处，首先是团队中的共享上下文。 每个人都确切地知道为什么要做出每个决定，从而减少以后的返工，并提高了质量标准。 如果这是一个研讨会，也是如此。 第二个好处是细微差别。 使用Randori方法可以帮助团队中的每个人都有机会为暴民编程做贡献。

Remotely, this is actually quite easy to achieve, as all participants would simply join in the same video conference room and the control of the keyboard is given to one person at a time (the driver). A handy tip is to have the order in which people become navigators/drivers on a list, so people know when they’re coming up to be the navigator/driver.

从远程来看，这实际上很容易实现，因为所有参与者都可以简单地加入同一个视频会议室，并且一次只能将一个键盘的控制权交给一个人(驾驶员)。 一个方便的技巧是确定人们在列表中成为导航员/驾驶员的顺序，以便人们知道他们何时成为导航员/驾驶员。

All up, while there are different formats to pairing, each lends itself towards different purposes. There is no “right” way of pairing. Simply experiment, adapt, adjust, and see what works for your team.

总而言之，虽然有不同的配对格式，但是每种配对都有不同的用途。 没有“正确”的配对方式。 只需进行实验，调整，调整并查看对您的团队有效的方法。

翻译自: https://medium.com/better-programming/different-ways-to-pair-program-even-if-youre-remote-b79b8da208cf

取消远程ssh的key配对