✨ 👨🏼‍🌾 ♍️ エクストリームプログラミング：ペアプログラミング 🕋 🍱 💧

ペアプログラミングはXPプラクティスの1つです。このプラクティスは、Code Reviewの極端な（誇張された）アイデアを具体化します。レビューでコードの品質を改善できる場合は、新しいコードをリファクタリングして記述している間、常にそれを実行しましょう。

通常のコードレビューの問題は、プログラマがコードを見るだけで非常に表面的なフィードバックを与えることです。しかし、彼らが彼と協力し始めるとすぐに、すべてのデリケートな場所と欠点に本当のフィードバックが届きます。

どうやってやるの？

ペアプログラミングでは、2人が同じコンピューターに肩を並べて座ります。それらの1つは「ドライバー」で、キーボードとマウスを手に持っています。 2番目は、最初のコードを絶えずレビューして、既存のシステム設計に適合しない構文、プログラムロジック、タイプミス、および実装のエラーを含む、コードの戦術的および戦略的欠陥を特定します。一定の時間が経過すると、プログラマーは役割を変更するか、ペアを変更します。

リサーチ

最大の懐疑論は疑問を提起します。2人のプログラマーが同じタスクに従事している場合、開発は遅くなりますか？

ペアで作業すると 、個別と同じ速度で 、または少し（15％）遅くなります。しかし、コードははるかに優れており、エラー（60％）と技術的負債が少なくなっています。

以下の研究の結果は、日常業務での私の観察と非常によく似ています。さらに、SUSUの教師として、コースの最初からペアプログラミングを始めました。私の結果は学年度の終わりになりますが、今のところはトピックに関する公的研究の選択：

ペアプログラミングからのボーナス

経験の交換：ペアで座って、作業をスピードアップするためのいくつかの新しいホットキー、興味深いユーティリティについて学ぶことがよくあります。いずれにせよ、他の人がどのようにプログラムするかを観察することにより、あなた自身が常に学びます。
システムの知識：ペアの絶え間ない変化は、チーム内のシステムのさまざまな部分に関する知識を広めるのに役立ちます。これにより、システムの開発方法を理解し、システムの設計を改善し、ロジックを複製することはできません。
集合的なコードの所有権：システムのすべての部分の作成に全員が関与している場合、クラスまたはアセンブリの個人的な所有権について話すことはできません。
メンタリング：私たちは皆プログラミングを始めました。実践が示しているように、プロジェクトへの最も単純な注入は、ペアプログラミングのプロセスで発生します。
より多くのコミュニケーション：チーム内のコミュニケーションは信頼の構築に役立ちます。スタンドアップやレトロスペクティブは日常業務のコミュニケーションに追加されますが、これはペアプログラミングの可能性と比較することはできません。
エンコーディング標準：プログラマーはペアで座ってキーボードを常に渡し、ペアを変更し、プロジェクトで採用されているエンコーディング標準に関する知識を広めます。コードの品質をチェックするために自動ツールを固定する必要がなくなりました。
規律の改善：ペアで座って、パートナーに自分の興味とトレーニングのレベルを示したい。また、一時的にソーシャルに切り替えるのはかなり困難です。最新の面白い写真を閲覧するネットワーク。
ストリームペアリング： 1人のプログラマーがもう1人に「今何を解決していますか？」と尋ねると、2人ともタスクに没頭し始めます。このようなアプローチは、フロー状態の共役につながり、生産性を数倍向上させます。
中断の減少：カップルでは、次のように、サードパーティの要因で中断を少なくする必要があります。 2人の時間は1人よりも貴重であり、彼らの仕事は2倍の費用がかかります。

アンチパターン

ペアプログラミングは、正しく行われれば、単独でプログラミングするよりもはるかに興味深く刺激的なものになります。逆に、間違って行われた場合、単独で作業するのに比べて、ひどく退屈なものになります。

私の観察によれば、人々がペアで正しくプログラムすることは非常にまれです。ペアプログラミングのほとんどの試みは、次のアンチパターンのいずれかによって台無しにされます。

マスターを見てください：これは、カップルが自分の分野の第一人者であると考えるプログラマー（またはプログラマー）を持っているときに起こります。ウィザードによって生成されたコードに関する経験の浅い開発者からの質問には答えられません。彼が絶えずGoogleで読むために送られるとき、オプションがあります。マスターは急いで彼のパートナーにキーボードを渡すことはありません、そして、彼が彼女に着くとき、マスターはプロセスのすべての興味を失います。
独裁者：ペアの開発者の 1人は、現在のタスクに関連するすべての決定に関して常に最後通告の厳しい立場を取ります。このような状況では、相互支援やペアトレーニングの話はできません。
コーヒーを飲みに行く：カップルがコンピューターの前に座っています。開発者の1人がキーボードを受け取り、コードの記述を開始します。パートナーは次のように述べています。「コードを書いている間に、コーヒーを注いでください。」これは、プログラマーがプロセスに相互に関与するという基本的な考え方に違反します。
サイレントパートナー：コンパニオンは互いに通信せず、作業中の行動や決定についてコメントしません。フィードバックがない場合、ペアの意味は失われます。
1つのテーブルでのタスクの分離：プログラマーはカップルに座って、1つのテーブル（デスクトップとラップトップ）で2台のコンピューターを取り、並行して作業を開始します。
座るのが不便：ペアで作業する場合の疲労の最も一般的な原因は、現在「ドライバー」であるキーボードとモニターの不快な位置です。キーボードがあるプログラマーから別のプログラマーに移動すると、キーボードを受け取ったプログラマーはテーブルの中央に移動せず、キーボードに向かって曲がるため、それ自体が困難になります。
パートナーは自分のビジネスで忙しい：パートナーの1人は、ペアで作業している間、職場から離れ、メールをチェックするなど。
カスタム環境設定：あるパートナーから別のパートナーに制御が渡されるたびに、環境は再構成を開始します：ブックマーク、フォントなど。
独自のスタイル：各パートナーは独自のコーディング標準を順守しており、議論が白熱し、コードがひどくフォーマットされています。

修正方法

これらのアンチパターンに取り組んでいる数人のプログラマーに気付いたら、フィードバックを与えてエラーを指摘してください。実践では、ペアの作業は外部の観察者が非常に簡単に設定できることを示しています。

適用の限界

実際には、ペアプログラミングを使用することは、XPの精神に起因するように見える可能性があるため、時間の約20％であり、常にではありません。もちろん、この割合は概算でプロジェクトによって異なりますが、一般的には100％には達しません。それでも、あなたはただ座ってコードを黙想し、美しいことを考え、このコードをさらに良くする方法のアイデアを出したいことがあります。

問題は、ペアで実行する意味がないタスクがあることです。

研究タスク：研究を行う必要がある場合は、Googleを利用して、現在の問題について専門家とチャットしてください。
ルーチン：次の手順が絶対に明白な場合、ペアでの作業は退屈になりすぎる可能性があります。
並列化する必要があります。2つの完全に異なるタスクがあり、締め切りが厳しくなっている場合は、ペアで座るのではなく、それぞれ独自のタスクを実行するのが論理的です。

ペアプログラミングはマラソンで勝利をもたらし、短いプロジェクトを行うとほぼ致命的であることを理解する必要があります。

すべての問題に対する万能薬ではなく、ペアプログラミングをツールとして正しく認識します。このプラクティスを試して、どの状況で役立つか、それなしで何ができるかを理解してください。

参照資料

ExtremeProgramming.org：ペアプログラミング

ペアプログラミングとコードレビュー

ペアプログラミングの利点

レビューコードはあなたの魂を救います

幼稚園で学んだペアプログラミングについて本当に知っておくべきこと

ペアプログラミングの利点：2つのヘッドが1つよりも優れている

ペアプログラミング：100％ペアリングの欠点

エクストリームプログラミング：ペアプログラミング