ペア・プログラミングとコード・レビューは共にソフトウェアの品質を向上させると同時に知識を共有するための取り組みである。Agile (参考記事リンク)vs. Lean(参考記事リンク)、XP (参考記事リンク) vs. Scrum(参考記事リンク)、そしてvi vs. Emacsといった議論が収束した今、開発者たちはペア・プログラミング(参考記事リンク)とコード・レビュー(参考記事リンク)のメリットを比較し始めている。Theodore Nguyen-Cao氏はコードレビューを鶏、ペア・プログラムを豚に例えている(リンク)。
鶏と豚の話は アジャイル活動でよく(比喩として)使われる話である。ベーコンと卵の朝食を作る時、鶏は巻き込まれるだけなのに対して豚は深く関与する。つまり、'豚'というのはある行為に深く関与するという意味で使われる。一方で'鶏'というのは巻き込まれはするもののその関与が薄いことを意味する。
コード・レビューでは、誰かが書いたコードをレビューするために人々が集まります。各自意見はあるものの、全員が日々そのコードに取り組むわけではありません。その場では皆が関与しているように見えるものの実際にはたいした興味があるわけではないのです。皆、一部のコードを見て「このコードは読みやすく、ちゃんとしているだろうか」と自問しているだけなのです。とても消極的な観点です。一方で、ペア・プログラミングでは取り組んでいるタスクに深く関わります。(ペア・プログラミングをしてる人達は)一緒に書いているコードと密に接して共同で設計、配置などを考えます。両方のプログラマが能動的な役割を担い、同じ問題に一緒に対処しているのでその問題に対して感情的にも深く関与することになります。
Theodore氏(リンク)はさらにコード・レビュー時よりもペア・プログラミング時の方がフィードバックがしっかりしていると指摘している。ペア・プログラミングの際には開発者は継続的にコードを書き、点検し、そして変更する。反対にコード・レビューの際にはコードの点検は先送りされ通常は担当者がデプロイ可能であると判断した時に実施される。
一般的にはソフトウェアが導入された時期と修正された時期の間が開けば開くほど、バグの影響は劇的にそして時には指数関数的に増加していくと受け取られている。これに従えばペア・プログラミングの最中に見つかった問題の方がコード・レビューの最中に見つかった問題よりもはるかに影響が少なくなるということになる。勿論いずれの場合もバグが検出される前にソフトウェアをリリースしてしまうよりは安くつくことになる。もしかしたら両方やる価値があるのかもしれない。
あなたはペア・プログラミングとコード・レビューのいずれが好みだろうか。あるいはどちらも嫌いだろうか。コメントを残して考えを共有されたい。
原文はこちらです：http://www.infoq.com/news/2009/01/Pair-Programming-Code-Review