コードレビューは緩いペアプログラミング

記事は古いけど、気付いたことをメモ。

【元ネタ】
【ITpro Challenge!】「高い生産性を実現する『ハッカーのソフトウエアエンジニアリング』とは」---Google 鵜飼文敏氏：ITpro

(前略)
　開発もなるべく小さな単位で行う。「設計しつつ実装，こまめにマイルストーンを設定する。小さい単位で動くものを作る。作る順序は後で使うものから。テストしやすさ，デバッグしやすさのために重要」（鵜飼氏）。
　既にあるコードを利用して，新たに作らないことも重要だ。「何を作らなくていいか，利用できるか，把握する。持ち駒が多ければ多いほどいい」（鵜飼氏）。
　Googleに入って感じたのはコードレビューの有用性だという。「コードレビューはとてもいい。ゆるいペアプログラミングのようなものでお互いのコードをチェックできる。ペアプログラミングは時間が拘束されるが，コードレビューならいつでもどこでもできる」（鵜飼氏）。
　デバッグの際はバグが存在する範囲を狭めて絞り込んでいく。あるいは狭めるようなテクニックをあらかじめ仕込んでおく。
(後略)

生産性：知識ゼロから学ぶ ソフトウェアテスト：So-netブログ

(前略)
個人的にはなるべく優秀な人を優遇したgoogleなりmicrosoft方式が気にっている。ソフトウェアプロセスも重要だと思うけど、優秀な人はCMMIがなんだかんだ言う前に日々現実的な作業改善をしている。
なんかペアプロよりこコードレビューのほうがいいというのも共感する。
(後略)

XPのプラクティスの一つであるペアプロは、二人の目による品質チェックと設計情報や技術ノウハウの共有という二つの利点がある。
実際の現場では、ペアプロを意識して実施されることはないが、本番リリース作業やDBメンテ作業など失敗が絶対に許されない状況では、自然にペア作業を行っている。
また、要件定義プロセスで複数人の設計者がペアで設計したり、初めてのアーキテクチャを使ってプログラミングする時は自然にペアプロしている。

しかし、ペアプロは同じ場所に二人同時に在席する制約があるため、疲れやすい。
コードレビューならば、非同期にペアプロできるのでいつでも可能だし、緩やか。

チケット駆動開発では、ワークフローを徹底すると、自然にペア作業になる。
例えば、バグ修正(PG)とバグ検証(テスター)、作業(PG)と承認(PL)、質問(開発者)と回答(設計者)、のように。

このプロセスをチケット駆動開発やコードレビューWebシステムで補完できないか？