コードレビューはペアプログラミングの代替手段

garyoさんに教えてもらった「Google 工藤拓さん講演「大規模ソフトウェア開発を支えるGoogleのテクノロジー」」の感想を書く。

【1】コードレビューができないプロジェクトの問題点

コードレビュー以前に、レビューというプロセスが存在しないプロジェクトは数多い。
相次ぐバグ修正や仕様変更にひっきりなしに対応するのに追われて、設計書やコードを書いただけになってしまいがち。
特にデスマーチプロジェクトでは、雑な作業の結果である雑な成果物ばかり作られる。
読んでも誰も分からない、とか、誤植が多い、などの症状が頻発するだろう。

レビューのない開発チームでは、設計思想や運用ルールの情報共有ができていない。
どんな開発でも、フレームワークやハードを含めたアーキテクチャの上で設計してプログラミングする。
その思想を理解するには、最初は時間がかかる。
特に昨今のWebシステム開発では、3カ月おきに開発者が入れ替わりがちだから、途中加入の開発者は設計思想や運用ルールに慣れるまで生産性が落ちる。

また、プログラミングには誰でも癖がある。
色んな人に見られた方がプログラムの可読性は必ず上がる。

だからこそ、レビューを上手に使って、チームに早くスムーズに溶け込めるように使いたい。

【2】コードレビューはペアプログラミングの代替手段

Googleはコードレビューに力を入れている。
上記Blogの下記のフレーズが気に入った。

(コードレビューは)ペアプログラミングの良い代替手段
(コードレビューは)開発者間の信頼関係を築く
　システムの引き継ぎが容易
　次のプロジェクトに行きやすくなり、流動性が高まる

XPのプラクティスの一つであるペアプロには、賛成も批判も多い。
しかし、ペアプロの目的や利点をはっきりさせれば、導入したくなるはずだ。

実際の開発や運用では、ペアで作業する場面は多い。
本番リリース作業や本番のデータ保守作業は、普通は2人でペアで行うのが普通だろう。
本番作業では1度のミスも許されないから、それだけのコストをかける価値がある。

また、新しい技術を取り入れて技術検証する時などは、席は離れていても、実質2人で議論しながら試行錯誤する時が多いだろう。
普通は一人で考えても上手くいかないから。

コードレビューの目的や利点は、上記Blogから考えると下記2点に尽きると思う。

1.ペアプロの代替手段
2.プロジェクトの引継ぎが楽になる

コードレビューとはペアプロであり、それによって情報が共有され、信頼関係が作られるからこそ、作業の引継ぎがスムーズになる。
コードレビューはあら探しではないのだ。

XPのペアプロは必ず同席という物理的制約があるが、ReviewBoardやCodestrikerなどのコードレビューWebシステムを上手に運用すれば、チャットのような感覚でコードレビューできる。

更にコードレビューしたコメントをチケットのように、重要度や優先度、作業状態を付けて管理できれば、ソースの品質は更に高まるだろう。