コードレビューの歴史

コードレビューの歴史に関して良い記事があったのでメモ。

【元ネタ】
コードレビューいろいろ - steps to phantasien

コードレビューは非同期ペアプログラミングとも言える。
二人の目を必ず通すことで、ソースの品質をチェックする。

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

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

コードレビューでよくあるのは、ウォークスルー。
コードレビューされる人が司会者となり、別のレビューアにコードレビューしてもらう。
ウォークスルーは、司会者によほどの力量がない限り、あまりうまくいかない。
一人の人の役割が大きすぎるからだ。

「Code Complete第2版―完全なプログラミングを目指して」のような本では、インスペクションが推奨されている。
インスペクションは、モデレータ、書記など役割分担がはっきりしており、事前準備の計画、議事録、レビュー後のチェックなどのプロセスが定義されている。
厳格なだけに実施するための準備が多いし、インスペクションの経験者がいなければうまく回らないだろう。
CMMやTSP、清水吉雄さんが提唱されているXDDPでよく使われていると思う。

コードレビューをサポートするツールは、Googleが自社開発のために作ったMondrianが一番有名だろう。
そこから各種のオープンソースツールが生まれた。
多分、ReviewBoardが一番有名だろう。
今なら、Gitと一体化したGerritが有名かもしれない。

コードレビューで多いスタイルは、コミット前のレビュー。
ReviewBoardではプレコミットレビューの機能が既にあり、充実している。

ReviewBoardでプレコミットレビュー: プログラマの思索

コミット後レビューで多いのは、Diffメール。
SVNにコミットしたら、その差分をメーリングリストに流す。
Diffメールを使うプロジェクトは今でも多いだろうし、Diffメールからコードレビューに発展する時も多いだろう。

コードレビューいろいろ - steps to phantasienの記事で面白かったのは、Bugzillaに既にパッチの差分ファイルを添付することでコードレビューする機能がプラグインとして提供されていたこと。
BugzillaのプラグインSplinterを使うと、差分表示してくれるらしい。

Splinter ? patch review for Bugzilla ≪ fishsoup

また、Bugzillaにはパッチのレビューのステータスを管理する機能もあるとのこと。
この機能があるだけでも、全く違ってくるだろう。

(引用開始)
Bugzilla は Mozilla によって開発され, WebKit でも使われている. Bugzilla にはファイルを添付できる以上の大仰なレビュー支援機能はない. そのパッチがレビュー要求であること, パッチのレビューが受理されたことを, フラグとして管理できるだけ. でもフラグをはじめとするメタ情報を検索でフィルタできるから, メールよりはレビューの進捗を把握しやすい.
(引用終了)

RedmineやTracなら、パッチの添付ファイルは差分表示してくれるし、コードレビューそのものをチケット化することで、一つの作業とみなせる。
ツール自身もどんどん進化している。
だが、コードレビュー専用のツールの方が使いやすい場面も多いかもしれない。