アジャイルなレビューをサポートするツールを5つ

感想おまちしてます!

Agile2010のリサーチセッションで、アジャイルソフトウェア開発におけるレビューをテーマに発表をしている方がいらっしゃいました(資料はこちら)。発表者はMario Bernhartさんだったと思うのですが、彼は発表の中で、Continuous Changeset-Based Review(CCBR)という言葉を使っており、開発の最後でレビューに時間をかけるのではなく、コミットごと(Changesetベース)のレビューという戦略を考え、CCBRを実践するためのツールとしてReviewClipseを紹介していました。

開発におけるレビューのコストは大きいと思います。アジャイル開発だけでなく、通常の開発もサポートする効率的なレビューツールを探してみました。

Mylyn Reviews (ReviewClipse)

BernhartさんおすすめのReviewClipseMylyn Reviewsというプラグインに生まれ変わっていました。

Screen shot 2011-04-10 at 6.15.46 PM

BernhartさんはEclipseCon2010でも発表されたみたいで、資料も公開されています。Mylynと連携することで、レビュータスクの管理が可能になります。Java開発者にとっては、Eclipseベースのプラグインは使い勝手がよさそうにみえます。

Redmine Code Reviewプラグイン

r-labsで開発されているRedmine Code Reviewプラグインです。

Screen shot 2011-04-10 at 5.05.03 PM (1)

レビューでの指摘事項がそのままチケットになるため、レビュー結果をスムーズにタスクとしてCloseしていくことができます。Redmineでリポジトリ連携をされている場合は、このプラグインはとても役に立つはずです。haruさんのアイコンかわいー。

Peer Review プラグイン

Trac HacksでみつけたPeer Reviewプラグインです。

Screen shot 2011-04-10 at 4.54.05 PM

Redmineのレビュープラグインより、Tracのほうが先にリリースされていた記憶があります。BTSとレビューツールは相性が良いので、Redmine Code Reviewプラグインのように、Tracユーザであれば導入を考えたいプラグインだと思います。

ReviewBoard

ReviewBoardはVMWareのレビューで使われていたツールがOSSとして公開されたものです。デモもあるので使うまでにチェックできます。

Screen shot 2011-04-10 at 4.50.18 PM

これまでのツールとは違い、リポジトリビューアを使ったレビューではなく、diffをアップロードしてレビューを行います。

実際に導入して気がついたこととしては、

  • Python環境を作るのが大変で、アップデートにも失敗したりした
  • Eclipseでdiffを作るとアップロードに失敗した(どうも不正なdiffをEclipseがつくる模様)

など、便利なのですが何かと手のかかるツールでした。

Crucible

商用ですがCrucibleも素敵なレビューツールです。

Screen shot 2011-04-11 at 10.31.45 PM
オンラインでデモを試せますが、さすがに高性能。ソース検索のFishEyeと使えば、生産性は間違いなく上がると思います。ポストコミット、プレコミットのどちらでもレビューが出来るみたいです。

デモを調べていて気がついたのですが、ソースコードを中心としたSNSみたいですね。@Sean_SFさんがおっしゃっていましたが、Atlassianの開発では、Crucibleをチャットみたいに使ってレビューをしているそうです。リアルタイムオンラインレビューできるコミュニケーション能力はすごい。

プレコミット vs ポストコミット

Review Boardならコードレビューを効率良くできる! via @ITにも書かれていますが、レビューにはそのタイミングによって、プレコミットレビューとポストコミットレビューに分けられます。

Redmine Code ReviewプラグインやPeer Reviewプラグインのようなツールは、コミットしたソースに対してレビューを行います。一方、ReviewBoardでは、コミット前に取得する差分ファイルを使って、プレコミットレビューを行います。

好みにもよると思いますが、リポジトリにはテスト済みの安全なコードがコミットされていてほしいはずです。しかし、ポストコミットレビューの場合、レビュー前のソースをコミットすることになるので、安全ではないソースが、開発チームに配布されてしまう可能性があります。ポストコミットの場合は、使い方とレビューの流れをよく考える必要がありますね。

まとめ

以前、公共事業系プロジェクトを経験したことがあるのですが、その時は

  • 机上でチェックリストを使ってチェック
  • ソースを印刷してチーム全体でレビュー
  • コミット、リリース

という流れで、時間をかける分、品質はとてもよかったです。

はじめはRedmine Code Reviewプラグインを利用していたのですが、SVNの負荷が問題になって一旦停止。その後、レビューの時間がチームでも問題になったため、ツールをやめてペアプロ試してみました。その結果は、ペアによっては、開発時間が半分に短縮できたり、倍の時間かかったりすることがわかりました。ペアの経験値によってコードの質も変わります。チームとして「ソースコードの共同所有」をする必要があったため、現在は、

  • ペアプログラミング (二人で共有)
  • ReviewBoardでレビューをメンバーにブロードキャスト (チームで共有)
  • コミット、リリース

という流れで進めるようにしています。それでもまだまだ遅いので改善中です。もっとクールな方法があれば、ぜひ教えてください。