2007-01-11

最近みた TechTalks: Mondrian Code Review On The Web

Python の親玉である Guido Van Rossum が, Google での初仕事(?) として Mondorian というコード・レビュー用ウェブアプリを 作ったよ, という話. ミーハー的に視聴.

前半はレビューとは何か, なぜそれが必要なのか, OSS でのレビューなどについて説明し, 後半から Mondrian 以前の Google 社内でのレビュー体制とその問題点を指摘, Mondrian の話と続く.

Google では SCM に Perforce を使っており, レビューは patch + メールベース. Mondrian 以前は Perforce の CL クライアントをラップする g4 というスクリプトを使ってレビューを支援していた. これを使うと patch をメールでレビュアに飛ばしたりできる. その飛ばしたメールを起点にレビュアとレビュイが議論し, "lgfm" (looks good for me) となったらチェックインする.

レビューのところだけ見ると, Google は大半の OSS と似たやりかたをしている. つまり, チェックインの前にメールベースで patch をレビューする. チェックイン前にレビューをするのは, Google の codebase が基本的に ブランチなしの trunk 一本だからだという. trunk にはヘンなものを入れたくないわけ. (trunk 一本が良い方法なのかはわからないけれど...)

OSS の方法と似ている以上, OSS のプロジェクトと同じような問題がある. まず, 他人の修正によって patch はすぐに陳腐化する. だから review が終わった時点ではもう obsolete でした, というのはよくある.

それに patch 単体では見通しが悪いから, レビュイは実際にそれを apply してから眺めたい. でも自分がいじってる作業コピーは変更したくない. 複数の patch をレビューする必要があるなら(活発に作っていたら普通におこる状況), それぞれの patch を適用するために作業コピーが手元に必要になる. かなりかったるい.

メールも問題だ. 紛失することもあるし, 見落したまま放置してしまう可能性もある. そもそも添付ファイルを保存して apply して...という時点で面倒だろう. (メールの他に sourceforge の patch manager の話も出てくるが, これも does not help だとしている.)

レビューは指摘と修正を反復する. レビュアはその修正の遷移を見たいけれど, 手元にあるのは複数の diff だけだ. diff の diff, みたいのはない. 少しずつちがう(でも大半は同じ)変更を眺めているど, だんだんうんざりしてチェックがおざなりになる.

レビューの仕組みは開発者のルールとしてまわっているもので, それを強制する仕組みはない. だからうっかりレビューなしでチェックインしてしまっても, 誰もきづかないままかもしれない.

...というような問題を解決すべく作ったのが Mondrian である. というのが前半の話. (上の説明は私の補足が色々入っており, Video とはやや内容が異なります.)

Mondrian

入社後, さて何を作ろうか考えていたところに先人の提案を受け, Guido は Web ベースのレビューツールを作ることにした. それが Mondrian. 実物は Video を見るのが手っ取り早い. デモがある.

基本的には patch manager と patch viewer と議論用 form のセット. Trac や ViewSVN みたいな Web ベースの SCM ビューアがあるけれど, ああいうかんじで patch の差分を表示できる. また, 同じく Trac のバグ(ticket) のように patch を一覧する機能もある. コメント相当の部分にレビューの議論を記録する. 議論のコメントはコードの特定の行にくっつけることができる. この "inline comment" が目玉機能らしい. 差分表示の画面からコード行をクリックして, 直接コメントを書き込める. (このへんは Ajax なんだぜ, と自慢していた.) たしかに欲しい.

g4 を使ったワークフローからのインクリメンタルな移行を支援するため, メールと web の相互乗り入れはけっこう頑張って作ったといっている. たとえば(おそらくシステムへと CC される)メールのヘッダをパースして, パッチやバグ(?) の ID があったらそれを Mondrian のコメントに反映する. 逆に Web のコメントからメールへのながれもある. このへんは社内固有の話で面白い.

社内固有といえば, Google は開発者毎に "Dashboard" というポータルページがあるらしい. Mondrian もその一部に組みこまれているかリンクしていた. Mondrian の Dashboard には, "自分がすべきレビュー", "自分が結果を待っているレビュー" の一覧が表示される. 時間に応じて色がきつくなるあたりがお茶目でいい. Guido の Dashboard にも真っ赤な項目が 1 件あり, なにか言い訳していたのが面白かった. (ところでこの "Dashboard" は, UI の世界だと割と知られた概念なんだろうか. 以前 Amazon を見ていたら "Infortion Dashboard Design" という本があり, これひとつで本になるのかといぶかしんだ記憶がある. まあいいけど...)

実装には, Perforce を叩くのに p4lib, ストレージには BigTable を使っているという. よっ, でました BigTable! ここでも履歴を保存できる機能が有効活用されているという. Scalable でいいぜ, みたいな話をしていた. そのほか, 何かの都合でユーザ毎にコードの snapshot をとることがあり, その時には NFS でユーザの workspace を直接見るのだろう. つまり社員の Workspace は基本的に公開されているわけ. すごい. 善し悪しはともかく, Google らしさのようなものはある.

今は多くの社員が Mondrian を使っているという. 全て Python で書いているけれど性能上の問題はあまりなく, 処理時間の大半は BigTable なり Perforce なりの外側のサービスだと言っていた.

おしまい. スライドが丁寧なせいであんまし英語の勉強にはなっていない...

レビュー支援ツールあれこれ

さて, Web ベースのレビュー支援ツールには庶民の手に届くものもある. (IEEE DL が読める人は 紹介記事 参照.)

Bugzilla

たとえば, BTS の古株 Bugzilla は patch ビューアを備えている (マニュアル. 以前紹介した Cycle Collector のバグ(Bug 333078) を 例にとると, ページの添付ファイル一覧には "Diff" というリンクがあり, ここから patch を diff 形式で表示できる. Mozilla の開発ワークフローは Bugzilla に集約されている: 彼らはここに patch をアップロードし, レビューの議論を行う. このように Mozilla コミュニティは Bugzilla をレビュー支援ツールとして使っている. Guido のいう OSS 流より少しはましになっているがわかるだろう. 少くともメールを紛失することはない. とはいえもともと Bugzilla の UI は若干 ugly な上, patch ビューアの出来は寂しい. 改善の余地は大きそうだ.

Codestriker

こちらはよりレビューに特化している. patch ビューアだけでなく, インラインコメントもサポートしているらしい. UI が地味なので, Trac くらい熟れた UI になれば流行りそうに見える. ただレビューツールという立場上, 既存 BTS との連携が弱そうなのは気になる. 路線としては Bugzilla のような BTS の追加機能として作る方が良いのかもしれない.

Jupiter

Eclipse の plugin として動く, らしい. Web ベースではないな.

Crucible

商用のツール. まだベータみたいだけれど, Clover や FishEye を開発している Cenqua の製品なので気になっている. (ブックマークしたのは昨年 9 月だった. リリースはまだかなー.)

このように, 色々やろうとしている人はいる. 個人的には Trac に Dashboard と patch ビューア(ちゃんと文脈を参照できるやつ)と Ticket 連携つきインラインコメントが付けば決定打だと思う. Guido を崇める Python ファンの若者が勢い余って作らないかと期待しているけれど, 甘いかしら.

レビューを afford するツール (が欲しい)

もっとも現実には, こうしたツール支援以前に難しいのがレビューそのものの運用だろう. Mondrian が強いのは, Google に存在した(であろう) solid な開発スタイルに フィットする形でアプリケーションを作った点にあると思う. 良い開発プロセスがなければ良いツールは生まれない. 逆に, よいレビューをしている人達が必要に応じて作ったツールを公開したら, そのツールによってレビューそのものが afford され, 草の根ソフトウェア開発の底上げがおこるかもしれない. あるスーパーグダグダプロジェクトが, Trac を使いはじめてからいくらか改善されたのを見たことがある.

かくいう私もここ一年レビューをしていない. 確実にコードの質は落ちている. 悲しい. レビューしたい. みんなレビューしましょう. ひまな人は "レビューで手を抜く" も 参照ください.