ペアプログラミングの考えられる欠点は何ですか？
ペアプログラミングは、今日では非常に有名です。
次のようないくつかの利点があります。
- バグの少ないプログラム。
- ポストプロダクションメンテナンスコストははるかに少なくなります。
- 確立された慣行は挑戦され、新しいアイデアの出現をもたらします。
- プログラマーは互いに学び合う。
- プログラマーはソフトスキルを開発します。
しかし、ペアプログラミングの欠点は何ですか？
ペアプログラミングはかなりの評判を得ていますが、いくつかの落とし穴もあります。
それらの一部は次のとおりです。
- ペアプログラミングでは、座って自分のコードを自己評価することはできません。
- ペアの1つが積極的に関与するのを停止する場合があります。
- ドライバーは「声を出してプログラムする」必要があります。サイレントプログラミングは利点を減らします。
- 同じ機能を作成するには、より多くの工数がかかります。コードの品質とコーディングコストの増加とのバランスを維持する必要があります。
- 経験豊富なプログラマーと初心者プログラマーがペアになると、「マスターを監視する」現象が発生する可能性があります。初心者のメンバーは、経験豊富なメンバーがほとんどのコーディングを完了するオブザーバーになることがあります。
- 2人の経験豊富なユーザーがペアになると、各メンバーが自分のアイデアをプッシュしようとする「開発者のエゴ」現象が発生する可能性があります。
私はペアプログラミングを数回試みましたが、すべてのエンジニアにとって必須のプロセスとして展開することを（簡潔に）検討した組織を含みます（そのアイデアがどれだけうまく機能しているかを推測できます）。個人的には嫌だった。
以下に挙げる理由は、私の主観的な経験にすぎず、具体的な影響を「測定」することはできません。しかし、ここではそれらはすべて同じです：
1-「ナビゲーター」と「ドライバー」があることは、前者がボーカルで、後者が聞く場合にのみ役立ちます。
私たちは皆、頑固で、理論的な懸念に熱心であるか、誰かが古い作品に問題を示唆したときに病理学的に-心理的に-古い作品を「捨てる」ことができない開発者に会いました。そして私達は皆、懸念を提起したり、コーナーケースを提案したりするのに臆病または自信がない個人を知っています。
これらの種類の開発者がペアになると、ナビゲーターはすぐに受動的な役割を果たし、最終的には自動コードレビューによる唯一のプログラミングになります。これは、莫大な資源の浪費です。
2-ペアリングは創造性を妨げます。
「グループブレーンストーミング」の価値について以前に感じられていたのとは対照的に、最近のコンセンサスは、創造的な知識の仕事には独立性とautonomy。一人で作業しているときは、クレイジーなアイデアをすばやくハックして、それが実際に実現可能かどうかを確認できます。 誰も知らないため、奇妙なプロトタイプを無言で組み立てることができ、失敗してもそれは問題ではありません。
それをペアリングと比較してください。新しいコンセプトを試してみたいときは、パートナーを説得し、実装について段階的に説明し、失敗しても私に判断されないようにしてください。そのような環境は毒性で新しいアイデアを生み出します。
-最も一般的な分母の設計。
上記のようにペアが新しいアイデアを生み出すことができない場合、または機能をどのように設計すべきかという基本原則に個人が同意できない場合は、妥協して誰も満足させようとしない混乱した設計が生まれます。
素晴らしく、雄弁で、空のように機能するプログラミングアブストラクションを構築する開発者と速くて汚いパフォーマンスフリークを組み合わせる場合、それらが一緒に生成するコードは、通常、ひどくエレガントでも特に高速でもありません。
4-自律性の欠如と暴力的な透明性。
暴力的な透明性は、スクラム方法論に対して中程度に有名な（そしてかなり物議を醸す）論争から私が選んだフレーズです。これは、一部の組織が開発者を幼児化し、通常は非専門家労働者のために留保されている疑いでそれらを扱う方法を説明しています。
開発者の作業を完全に透過的にすることの「害」について何を考えても（実際には害であることに同意できないかもしれません）、多くの個人は、自律性と一人で働く能力を評価し、正しいことを行うと信頼されています。これは重要な心理的な必要性であり、開発者にペアリングを強制すると（少なくとも1つのショップで見られるように）、従業員は失望し、動揺し、疎遠になります。
5-一部の開発者は、ペアでうまくプレイしません。
ペアリングされた環境で適切に行動しない、またはできない人もいます。彼らは、衛生状態が悪い、仕事の習慣が悪い、性格が研ぎ澄まされている、「騒々しい」「強烈な」態度、または他の多くの属性を持っているため、個々の労働者はすばらしいが、ペアのプログラマーは貧しい。
これを解決できますか？あんまり。個人の行動を変えることは難しいです。ペアプログラミングショップは、採用に非常に注意を払い、多くの時間を費やして、誰かがどのように働いているか、同僚とうまく仕事ができるかどうかを確認する必要があります。ただし、性格を厳しく区別することは、スキルと専門知識の基準を緩めない限り、採用に時間がかかることを意味します。
あなたの状況や視点に依存します。
ペアプログラミングは組織に適しています。しかし、それは個人にとって良いことなのでしょうか？
結局のところ、それはコスト削減（早期フィードバック）と生産性の方法です。それはあなたではなく、プロジェクト、製品、会社（$$）の問題です。
個人的なメリットはありますが、それが開発方法論の理由や目的ではありません。 （フルタイム）ペアプログラミングは、たとえば、スラックやサーフィンなどを停止させ、パートナーにポーズを正当化する必要があります。
あなたの（回転する）パートナーが最高の監視カメラになります。
または、知識を配布することにより、個人は会社にとってリスクが低くなり（たとえば、会社に本質的な知識を残すことができなくなります）、「交渉用チップ」が少なくなります。
マネージャーの視点ではなく、会社の実際の状況/立場から肯定的な記事を批判的に読むことで、より多くのポイントを見つけられると思います。
ほとんどすべての方法論はマネージャーの観点から書かれています。
突然、トイレに行ったり、コーヒーを飲みたいときは、誰かに話さなければなりません。少なくとも許可を求める必要はありません。
あなたは他の人の衛生基準に対処しなければなりません。
他の回答に加えて：
私が働いてきた多くの企業がプログラマーにラップトップを発行しました（クライアントのサイトをベース-仕事の後で家に持ち帰った場合に機器を安全に保ちやすく、ピンチでVPNで家から奇妙な仕事をすることができるなど）長年以前、私はすでにショルダーサーフィンの観点から他の人（「ドライバー」）のラップトップスクリーンを見るのに問題がありました-年齢はこれを改善しません（そして、いくつかのスクリーンはいずれにしても理想的な視野角の外側で読みにくくなります）。
そのため、ペアのプログラマーは十分に大きな画面を必要とし、ハードウェアのコストが増加し、場所への適応性が制限されます。一部の人にとっては問題ではないかもしれませんが、他の場合ではそれが問題になります。
- 私はまた、個人の衛生環境の好み（喫煙、食事、飲酒を含む）の違い、および性格の衝突が生産性を妨げる傾向があることも発見しました。 2人のプログラマーに「それを吸い上げて仲良くする」ように指示するのは簡単です。多くの場合、これは人々が口を閉じたままにし、お互いの恨みを発散させるパッシブアグレッシブなアクションを介して静かに互いに妨害します。
- ノイズ。私は、静かな職場環境が好きです。 （コミュニケーションのために話す必要があるため）ペアプログラマーのいくつかのグループからの絶え間ないおしゃべりを想像することはできません。ヘッドフォンのボーカルミュージックでさえ、私の集中力を妨げる傾向があります（オフィスで聴くための穏やかな楽器...）。これは、ユビキタスオープンプランのオフィスから専用の2人用のオフィスルームに移動することで軽減できると思いますが、それによって再びコストが増加します。
あなたの娯楽のための逸話：
- 以前の雇用主がかつて別の国から請負業者を雇っていた（有罪を保護するために匿名のままである）。雇用主は宿泊施設を提供したが、輸送は提供しなかった。上記の請負業者は私の仕事の道に沿って住んでいたので、私は彼を迎えに行き、彼を再び降ろすように志願しました。彼の個人的な衛生状態が、私が慣れているものと同じ基準ではなかったとしましょう。また、私はそうではありませんが、彼はたばこを吸った（「最強！」） 15分のオフィスへの旅行で、冬であっても窓を下にしたままにしました。これにより、同僚の3か月のスティントの後、車が古い喫煙室のような臭いを防げませんでした（いいえ、彼は車で喫煙していませんでした） 、しかし彼は私を待っている間にしました）。
- 私たちはペアプログラミングもしませんでしたが、（しばらくの間）会議の席で隣同士に座っていました。約1か月後、同僚のマウスの手の位置の周りのテーブルのにせの木材に、すてきな茶色のリングがありました。その時点で、私はコールセンターのオープンプランエリアのすぐ隣にオープンデスクを手に入れました。
- それから、ユビキタスなオフィス飲料、コーヒーがあります。私はそれを飲みますが、私は他の同僚がそうであるように、なくても仲良くできて、あまり飲みません。近距離での呼吸は非常に不快な場合があります-忘れられた空のマグの匂いに似ています。香りを「蒸し暑い」と呼ぼう...
ペアプログラミングは社会的および実用的な理由で失敗すると思います。基本的に、あなたは一人に一定の監視の下で働き、もう一人は穴をあける以外何もしないように頼んでいます。
しばらくすると必然的に起こるのは、ペアが「メールをチェックする」または「そのライブの問題について不正なチェックを続ける」などに分割されていることです。
コード出力を改善するのではなく、音量を下げます。実用的な理由の両方で「私はあなたと同期せずに昼食/会議に行く必要があります」と社交的です
自慢の利点については、よりシンプルで効果的な方法でこれらを達成する多くの一般的な慣行があります
2人の上級開発者に仕事ができると確信している場合に「苦痛なプログラミング」を行うように言うことは、彼の最大の欠点です。