一般的に、ピア レビューは開発プロセスの非常に良い部分であると思います。コードが最初に書かれたときには明らかでなかった事柄を見つけたり質問したりすることが多く、自分自身を意識させて、フォーマットを改善したり、コメントを入れたりすることができます。
しかし、ペア プログラミングを行っている場合、事実上ライブ ピア レビューが行われます。ペアレビューはできますか？
私が働いている場所でペア プログラミングが行われ始めているので質問します。一般的に、これはピア レビューの代わりと見なされます。確かではありませんが、開発者がペア プログラミングとピア レビューに費やす時間は、生産性を損なう可能性があると思います。
しばらく前に同様の質問がありましたが、重点が異なり、明確なコンセンサスはありませんでした
場合によります。
私の意見では、ピア レビューの目的は、記述されたコードの欠陥を直接見つけることだけではなく、コードが既存のコード ベースでも適切に機能することを確認することです。場合によっては、作成しているコードの専門家を関与させたい場合がありますが、その専門家はペアのメンバーではない場合があります。
たとえば、アプリケーションの 3D グラフィック部分を作成する場合、OpenGL の専門家にレビューしてもらいたい場合があります。
そのため、状況によっては、第 3 の目で問題を確認する必要がある場合があります。この人は、同じ場所にいることさえないかもしれません（別のタイムゾーンなど）。
さらに、ペアになると、同じように考える傾向がある場合があります。したがって、別の意見は、見逃したものに目を向ける可能性があります。
私の開発者がペアでコードを書いたとしても、彼らがコードのその部分の 100% の専門家ではない場合、コードをレビューしてもらうように彼らを扇動します。
ペア プログラミングでパートナーが変わると、基本的に自動的にピア レビューが行われます (1 組の「余分な」目だけではありません)。また、両方のプログラマーが何かを行う方法がわからない場合でも、助けを求めることができます (そうすべきです)。
両方のケースに関係するマインドセットはプログラミングの時点ではかなり異なるため、ピアレビューは依然として重要だと思います。通常のマインドセットは重要ではありませんが、ピアレビューを行っている間は重要な分析に関与するマインドセットです。それを開発した同じ開発者は、テスターからそれを完成させるほど良くないでしょう
ペア スイッチングは、ピア レビューの問題を解決することを目的としていました。開発者が新しいペアに参加するとき、開発者は自分が取り組もうとしている問題を理解する必要があります。そして、理解にはレビューが含まれます。
システムの重要なポイントについては、専門家が個別にレビューするだけでよいと思います。
ペアリングはピアレビューです。または、XPが言うように、何かが良い場合は、それを極端に持っていきます。ピアレビューが良ければ、それを継続的に行います。つまり、ペアプログラミングです。
ペアプログラミングが適切に行われ、ペアが頻繁にローテーションされると、開発されたすべてのコードの継続的なピアレビューを実行できます。さらに良いことに、コードは、コードが記述されて修正に費用がかかる後ではなく、設計、テスト、および記述されたときにレビューされます（はい、最初にテスト駆動開発としてテストを記述します）。
ピアレビューされたコードは、ペアプログラミングの利点の1つにすぎません。その他の利点は次のとおりです。
品質の向上：同じストーリーカードで作業しているアクティブなプログラマーのペアは、欠陥の少ないカードを完成させます
生産性の向上：問題を解決するときに完全にブロックされていない場合、ペアの速度が低下する可能性は低くなります。さらに、パートナーと一緒に仕事をしているときは、電子メールやWebでの休暇を取るのが難しくなります...パートナーを失望させたくありません。ペアで作業する場合、よりクリーンなデザインと少ないコード行で問題を解決します
知識のサイロを排除する：ローテーションペアを使用すると、チーム全体でアプリケーションとドメインのビジネス知識を学ぶことができます。スーが休暇を取り、他の誰も彼女のコードを知らないため、チームがブロックされる可能性は低くなります。
スキルの伝達：回転するペアは、一緒に機能するときに、新しいスキル（エンジニアリングとドメイン）を互いに教えます。チームのレベルはすべての人にとって上昇し、知識はチーム全体に伝播します。
チームの自己選択：チームは葯のスキルを習得し、パフォーマンスを行っていない人をすばやく排除します。