コードレビューWebシステムが必要な理由

最近、コードレビューWebシステムに興味を持っている。
アイデアをメモ。

【元ネタ】
プログラマの思索: ソースインスペクションを真面目にやるGoogle、MS

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

プログラマの思索: レビューはペア作業であるべき

最近思うのは、SW開発でレビュー工程が最大のボトルネックになっていること。

レビューは、設計書を作成完了した後、設計書に従って実装完了した後に行われる。
レビューの目的は二つあると思う。
一つは品質チェック。
他方は、チーム全体で仕様や設計思想を情報共有すること。

しかし、レビューがうまく機能していない。
実際は、レビューが品質強化につながっておらず、むしろ、要件定義の代替プロセスになっていたり、ソースチェックで自動化できるぐらいのレベルでしか、情報共有できてない。

僕の考えでは、XPのペアプロのように、レビューは二人のペアで、レビューイーのPCの前でレビュー結果を即反映していく方がはるかに生産性が高いと思う。
理由は、レビュー結果は紙ベースで残すため、伝言ゲームになりがちで、せっかくの仕様が漏れやすいから。
また、レビュー指摘事項を記録に残して、レビュー結果をいつ反映したか、というレビュー作業ステータスを管理するのは、又もやExcelのため、ステータスの追跡やステータス集計がやりにくい。

そこで、コードレビューWebシステムを導入してみることを考えている。
特にコードレビューは、場所や時間が離れた場でもレビューできる状況がBetterだと思う。

Perl製のソースコードレビューソフトウェア「Codestriker」

VMWareの開発でも利用されているソースコードレビュー共有ソフトウェア「Review Board」

上記は、コードレビューをWebシステム上で行うもので、僕としては画期的だと考える。
理由は、場所や時間が離れていても、誰でも簡単にレビューをコメント(チケット)として書いて残せること、更には、レビュー結果がDBにあるため、色んなメトリクスを出力できるから。

ReviewBoardには、二つのソースのDiff画面で、任意の場所にコメント(チケット)を付加できて、そのチケットのステータスを追跡できる仕組みがある。
この仕組みは、チケット駆動開発によるタスク管理と同じ発想。
つまり、レビュー指摘のチケットのステータス(未着手・レビュー修正中・レビュー反映完了)を追跡できるため、レビューのワークフロー管理を行うことができる。

Codestrikerには、レビュー指摘件数とレビュー作業のステータス(未着手・レビュー修正中・レビュー反映完了)を実施日でクロス集計して表示する機能がある。
この仕組みは、レビュー実績の信頼度成長曲線のようなもの。
つまり、ある程度のボリュームでレビューの指摘が上がり、それに対応していくと、ある時点でレビュー指摘件数が減り、最終的には品質が歩溜まりに達するだろうと考えられる。

だが、上記のコードレビューWebシステムが良いと思うのは、誰もが気軽にレビューコメントをチケット登録できることだ。
普通、レビューワーは業務知識を知り尽くしている人、プログラミング技術に長けている人がその役割を担うが、チームに新規加入した人や新人も気軽に質問できるような雰囲気が出てくる。

例えば、Googleにおけるコードレビュープロセスの概念では、信頼関係の強化が含まれている。
つまり、レビューワーとレビューイーがレビュー工程を通して、お互いの信頼関係を高めながら、仕様や技術を共有していくことが含まれている。
レビューは単なる欠陥のあら探しではないのだ。
レビューを通じて、チーム全体で設計思想を共有することで、どのメンバーでもシステムの運用保守をできるような環境を作る。
このような環境作りがあれば、特に、新人や新規加入メンバーのスキルアップに非常に役立つ。

しかしながら、コードレビューWebシステムを稼動できたものの、実際の運用はハードルが高かった。
特にコードレビューしていくと、リファクタリングに関係するチケットが増えてゆき、それらは内部課題やリスク管理のようなイテレーションに含まれてしまい、一般に優先度が低くなる。
だから、即修正する場合があまり増えない時がある。
理由は、まずチームにレビューというプロセスが無かったり、コードレビューの作業と、Redmineチケットの関係付けが曖昧だったから。

でも最終的には、レビューはペアプロとして実装され、そのレビュープロセスは、チケット駆動開発の一プロセスとして組み込まれるべきだと思っている。