Rietveldでレビューしよう
本当はいろいろ実地で試してから文章を書こうかと思ったんだけど、まあ、just an ideaということで。
Rietveldってたぶん、聞いたことがある人はプログラミング系の人以外にはないと思うのだけど、これって本とかの内容チェックなどにも普通に便利なんじゃないかなーと思う。そんなわけで、今回はRietveldっていうのがどういうもので、どういう問題を解決し、なぜ本とかのレビューにも向いているかという話をしたい。
Rietveldというのはコードレビュー用のシステムだ。GoogleではMondrianという名前のコードレビューシステムが使われている。これを外部でも使いたいということで、Mondrianの作者が作ったのがRietveldである(コードが共有されてるのかどうかは知りまへん)。実際に http://codereview.appspot.com/ などで公開されている。けど、オープンソースなので自分用にサーバを立てることも可能だと思う。
Rietveldが何をして、何を解決するか。
そのまえにコードレビューという仕事がどんなものか説明したい。プログラマがなんかのプログラムを書くとする。普通はなんらかの開発環境が手元にあって、手元で動かしたり、比較的自由に実験できる環境でプログラムをテストしたり、そういうことをいろいろやってどうもかけたプログラムはちゃんと動いてるっぽいとわかった。それじゃどうするかというと、サブミットという処理をして、手元の開発環境だけでなくて、他のみんなと自分の成果を共有する。そうやって開発を続けていく。
ただ、手元で動いたことがわかってもそれをいきなりサブミットするのはいろいろとまずいので、その前に同僚にレビューをお願いすることになっている。これがコードレビューだ。問題ないなら「オッケー」って言えばいいし、直して欲しいところがあれば「ここはこうしたほうがいい」とかツッコミを入れる。ツッコミを入れて直ったならオッケーになって、過程はともかくレビュアーが全員よしと言えばサブミット、という流れになる。
ただ、すぐにオッケー(GoogleではLooks good to meを略してLGTMと呼ばれる)を貰えればいいのだが、世の中というのは往々にしてそう簡単にはいかないもの。いろんな方面からいろんな人が口を出し始める。「ここはこうしたほうがいい」「ここはこうだろう」エトセトラエトセトラ。
よくあるコードレビューの場合、メールベースで行う。すると「◯◯っていうファイルの何行目はこうしたほうがいいね」「××っていうファイルの追加箇所はコーディング規約的にはこう書いた方がいいと思う」といったフィードバックが別々のメールでやってくる。それに対してひとつずつ返事をしていくわけだが、メールが多くなってくるとわけがわからなくなってくる。一つのメールに2つ以上のトピックが混じっていると、一方のトピックが忘れ去られる危険もある。かといって「全体的に直しました。よろしく」では意味がない。しかもメールの到着順序が前後したり、修正している途中や返信を書いている途中に他の人がまたレビューを送ってきたりすると混乱に拍車がかかる。また、返事の返事が錯綜してくると、どの段階でどこまで直ったのかがわからなくなってくる。
Rietveldはこういう状況を解決する。
Rietveldはウェブベースのシステムになっている。コメントや返事はメールでも送られるけれど、基本的にはサーバ上(クラウドの中、という方が最近はウケがいいのかな)に保存されている。どこから見ても、またレビュアーと元著者のどちらが見ても、基本的には同じものが見える。
また、コメントはファイルの途中に差し込まれるようにして挿入される。挿入されたコメントには返事も書けて、その場所にどんどん蓄積される。どのレビューコメントに返事をしていて、どのレビューフィードバックは直していないかが一目瞭然になるし、そのレビューコメントについても、議論の流れがすぐわかる。そういうわけで、メールが錯綜してわけわかめ、みたいな状況にはなりづらい。
もうひとつ重要なのはRietveldでは独自にスナップショットを取っているということだ。元著者が何かプログラムを書いて、レビュアーがコメントを残す。すると元著者はプログラムを書き直してRietveldにアップロードする。するとRietveld上では新しいパッチセットというものが作られる。基本的には最新のパッチセットが元著者がいろいろ直した最新版だからこれをレビューするわけだけど、前のパッチセットも残っていて、新しいパッチセットと比較ができる。つまり、元著者がどう直したかということもわかる。また、コメントはパッチセットに対してつけられるから、このコメントはファイルがどの段階のときにくれたコメントかというのは一目瞭然だし、コメントを受けてどう修正されて行ったかということもわかりやすい。
まとめると、Rietveldは、メールベースのレビューにおける次の問題を解決する。
- 一つのメールが複数の箇所をコメントしていたりするため、コメントへの返信などが錯綜し、コメントしたのに返答がないといったことが起こりやすい→一つ一つのショートコメントはファイルの特定の箇所にひもづけられ、そこで議論する
- 返信や修正の順番によって、どの段階のファイルに対するコメントなのかわからなくなる。→コメントはパッチセットに関連づけられるので問題ない
こういった問題って、でも、コードレビューだけじゃないと思う。いくつか技術的な文章のレビューというのをお願いしたり、されたりすることがまれにあるんだけど、メールベースのフィードバックは混乱するし大変だ。書籍ともなると分量も膨大だし、管理しづらい。
subversionとかissue trackerとかを使ってる出版社は技術系にはけっこうあると思うけど、この手のコードレビューシステムっていうのは、まだそれほど一般的ではない気がする。しかし、本質的に書籍の内容のチェックであるとかのワークフローっていうのは、根本的にはこういう事ではないのかな？ Rietveldが解決した問題に、まだ苦しんでいる世界は結構あるのでは。いっそのこと、論文のレビューだってこういうふうにやった方が良い気もする。
もちろん、Rietveldはコードレビューのためのシステムなので、文章のレビューのためには考えないといけないことがある(論文だとレフリーの匿名性とかの問題もある)。たとえば、文章はそもそもどんなフォーマットで書くか。HTML？ ふつうのテキストファイル？ 画像やイラストはどうレビューしたらいいだろうか。といったように、そのまま流用できるほど簡単ではないと思う。あとまあ、RietveldのUIはまるで国際化されていないし用語が完全にプログラマ向けなので、ふつうの日本人には使い方に慣れるまで時間がかかると思う。
でも、文章メインの世界だったらただのテキストファイルに画像ファイルがいくつかという形式でいいわけで、楽になると思うんですよね。なんかの機会でちょっと試してみたいかも。