ペアプログラミングの潜在的な欠点は何ですか？[閉まっている]

ペアプログラミングは、今日では非常に有名です。

以下のようないくつかの利点があります。

1. バグの少ないプログラム。
2. ポストプロダクションのメンテナンスコストははるかに低くなります。
3. 確立された慣行は挑戦され、新しいアイデアが生まれます。
4. プログラマーはお互いから学びます。
5. プログラマーはソフトスキルを開発します。

しかし、ペアプログラミングの欠点は何ですか？

ペアプログラミングはかなりの評判を得ていますが、いくつかの落とし穴もあります。

それらのいくつかは次のとおりです。

1. ペアプログラミングでは、自分のコードを離れて自己評価することはできません。
2. ペアの1つが積極的に関与しなくなる可能性があります。
3. ドライバーは「声に出してプログラムする」必要があります。サイレントプログラミングは利点を減らします。
4. 同じ機能を作成するには、より多くの工数がかかります。コードの品質とコーディングコストの増加のバランスを保つ必要があります。
5. 「マスターを見る」現象は、経験豊富なプログラマーと初心者のプログラマーがペアになると発生する場合があります。初心者のメンバーがオブザーバーになり、経験豊富なメンバーがほとんどのコーディングを完了します。
6. 経験豊富な2人のユーザーがペアになると、「開発者のエゴ」現象が発生し、各メンバーが自分のアイデアをプッシュしようとします。

私はペアプログラミングを何回か試みましたが、その中にはすべてのエンジニアにとって必須のプロセスとして（簡単に）展開することを考えていた組織も含まれています（そのアイデアがどれだけうまく機能したか推測できます）。個人的に、私はそれが嫌いでした。

以下に挙げた理由は私の主観的な経験に過ぎず、具体的な用語でその影響を「測定」することはできません。しかし、ここではすべて同じです：

1-「ナビゲーター」と「ドライバー」があるのは、前者が音声で、後者が聞く場合のみです。

私たちは皆、頑固で、何らかの理論的な懸念に熱心であるか、誰かが問題を示唆したときに古い仕事を「捨てる」ことが病理学的に不可能である-心理的に-開発者に会いました。そして、私たちは皆、懸念を提起したり、コーナーケースを提案したりするには、あまりにもti病であるか、または気が進まない個人を知っています。

これらの種類の開発者がペアになると、ナビゲーターはすぐに受動的な役割を果たし、最終的に自動コードレビューを使用した単独プログラミングになります。これはリソースの途方もない浪費です。

2-ペアリングは創造性を妨げます。

「グループブレーンストーミング」の価値について以前に感じていたものとは反対に、最近のコンセンサスは、創造的な知識の仕事には独立と自主性が必要であるということです。あなたが一人で働いているとき、あなたはそれが実際に実行可能であるかどうか見るためにいくつかのクレイジーなアイデアを素早くハックできます。奇妙なプロトタイプを無言で組み立てることができます。失敗した場合、誰も知らないので問題ではありません。

それをペアリングと比較してください：新しいコンセプトを試してみたいときは、パートナーを説得​​し、実装を通して段階的に話し、失敗しても彼らが私を判断しないことを望みます。そのような環境は、新しいアイデアを生み出すのに有害です。

3-最も一般的な分母の設計。

上記のようにペアが新しいアイデアを生み出すことができない場合、または機能の設計方法に関する基本原則に個人が同意できない場合、出てくるのは妥協しようとし、誰も満たさない混乱した設計です。

素晴らしく、雄弁で、空っぽな関数型プログラミングの抽象化を構築する開発者と、高速で汚いパフォーマンスの異常を組み合わせる場合、通常、彼らが一緒に生成するコードは、それほどエレガントでも特に高速でもありません。

4-自律性と暴力的な透明性の欠如。

暴力的な透明性は、スクラムの方法論に対して中程度に有名な（そしてかなり物議を醸す）論争から引き抜いたフレーズです。それは、一部の組織が開発者を乳児化し、通常は非専門職労働者に留保されている疑いで彼らを扱う方法を説明しています。

開発者の仕事を完全に透明にすることの「害」についてどう考えても（実際には害だとは思わないかもしれません）、多くの人が自律性と一人で働く能力を高く評価し、正しいことをすることを信じています。これは重要な心理的ニーズであり、開発者にペアリングを強制すると（少なくとも1つのショップで見たように）、従業員は動揺し、動揺し、疎外されます。

5-一部の開発者はペアでうまくプレイしません。

ペア環境では適切に行動しない人や行動できない人もいます。彼らは悪い衛生状態、劣悪な労働習慣、研ぎ澄まされた性格、「騒々しい」および「激しい」態度、または個々の労働者を立派にする他の多くの属性を持っているかもしれませんが、貧しいペアプログラマーです。

これを解決できますか？あんまり。個人の行動を変えるのは難しいです。ペアプログラミングショップは、雇用に非常に注意を払い、誰かがどのように働いているか、そして同僚とうまく働くことができるかどうかを確認するために多くの時間を費やす必要があります。ただし、人格をより厳しく差別するということは、スキルと専門知識の基準を緩めない限り、採用に時間がかかることを意味します。

あなたの状況や見通しに依存します。

ペアプログラミングは組織に適しています。しかし、それは個人にとって良いことですか？

結局のところ、それはコスト削減（初期フィードバック）と生産性の方法です。それはあなたではなく、プロジェクト、製品、会社（$$）についてです。

個人的なメリットを得ることができますが、それらは開発方法論の理由や目的ではありません。（フルタイム）ペアプログラミングは、たとえば、スラック、サーフィンなどからあなたを停止します、あなたはあなたのパートナーにあなたの一時停止を正当化する必要があります。

あなたの（回転する）パートナーが最高の監視カメラになります。仕事の強度が増します。

または、知識を配布することにより、個人は会社にとってリスクが低くなり（たとえば、会社に不可欠な知識を残すことができなくなり）、「交渉チップ」が少なくなります。

マネージャーの視点からではなく、会社の実際の状況/観点から肯定的な記事をより批判的に読むことで、より多くのポイントを見つけることができると確信しています。

ほとんどすべての方法論は、マネージャーの観点から書かれています。

1. 突然、トイレに行きたいときやコーヒーを飲みたいときに誰かに言わなければなりません。少なくとも許可を求める必要はありません。

2. 他の人の衛生基準に対処する必要があります。

他の回答に加えて：

1. 私が働いていた多くの企業は、プログラマーにラップトップを発行していました（クライアントのサイトに拠点を置いています-仕事の後に家に持ち帰ると、機器の安全性を維持しやすくなります。以前、私はすでに他の人（「ドライバー」）のラップトップ画面をショルダーサーフィンの観点から見るのに問題がありました-年齢はこれを改善しません（とにかく理想的な視野角外で読みにくくなる画面もあります）。

   そのため、ペアプログラマには十分に大きな画面が必要になり、ハードウェアコストが増加し、場所への適応性が制限されます。一部の人にとっては問題にならないかもしれませんが、他の場合には問題になります。

2. また、私は、個人の衛生上の好み（喫煙、飲食など）の違い、および人格の衝突が生産性を妨げることは明らかです。2人のプログラマーに「それを吸い上げて仲良くする」ように指示するのは簡単です。多くの場合、これは人々が口を閉じたままにし、お互いの-みを消すために受動的攻撃的なアクションによって静かにお互いを妨害します。
3. ノイズ。私にとっては、静かな職場環境が好きです。ペアプログラマの一部のグループからの絶え間ないおしゃべりは想像できません（コミュニケーションのために話す必要があるため）。ヘッドフォンで歌っている音楽でさえ、集中力を妨げる傾向があります（オフィスで聴くための当たり障りのない楽器...）。これは、ユビキタスなオープンプランオフィスから専用の2人用オフィスルームに移動することで軽減できると思いますが、それによってコストが再び上昇します。

あなたの娯楽のための逸話：

• 以前の雇用主は、かつて別の国から請負業者を雇いました（すべて、有罪を保護するために匿名のままでいる必要があります）。雇用主は宿泊施設を提供したが、交通手段は提供しなかった。請負業者が私の仕事のルートに沿って住んでいたので、私はボランティアで彼を迎えに行き、再び降ろしました。彼の個人的な衛生状態は私が慣れているものと同じ水準ではなく、私はそうではないが彼は重く（「最強！」）喫煙したとしましょう。オフィスへの15分間の旅行で、冬でも窓を開けたままにしました。これは、同僚の3か月のスティントの後、車が古い喫煙室のような臭いを防ぐことはありませんでした（いいえ、彼は車で喫煙しません、しかし彼は私を待っている間にした）。
• また、ペアプログラミングは行いませんでしたが、会議テーブルで（横に）隣同士に座っていました。約1か月後、同僚のマウスの手の位置の周りに、テーブルの合成木材に素敵な茶色のリングがありました。その時点で、コールセンターのオープンプランエリアのすぐ隣にオープンデスクがあり、それを（ヘッドフォンの助けを借りて）好みました。
• 次に、オフィスのいたるところにコーヒーがあります。私はそれを飲みますが、他の同僚と同じくらい頻繁に飲むことができます。至近距離での息は非常に不快な場合があります-空の忘れられたマグカップの匂いに似ています。香りを「マギー」と呼びましょう...

ペアプログラミングは、社会的および実際的な理由で失敗すると思います。本質的に、あなたは一人に一定の監視の下で働き、もう一人に穴を開ける以外は何もしないように頼んでいます。

しばらくして必然的に起こるのは、ペアが「メールをチェックする」または「そのライブの問題を悪意を持ってチェックする」などに分割されることです

コード出力を改善するのではなく、ボリュームを減らします。実用的な理由から、「私はあなたと同期していないランチ/ミーティングに行く必要があります」と社会的な「ボブが彼のしていることを終えるのを待ってから再びペアリングについて尋ねます、私は彼をしつこく見たくありません」

自慢の利点に関しては、より簡単で効果的な方法でこれらを達成する多くの一般的な慣行があります

2人の上級開発者に仕事ができると確信している場合に「痛みのあるプログラミング」をするように言うことは、彼の最大の不利益の1つです。