« 形式手法とHaskellについてメモ | トップページ | ソフトウェアテストPRESS Vol.9にあるTestLinkの記事 »

2009/10/16

ReviewBoardを使うプロセスとは?

コードレビューWebシステムReviewBoardを久しぶりに触ってみて、考えたことをメモ。

【元ネタ】
ReviewBoard 釣られて使ってみた | tsuyuki.makoto

Review Board is good software - O'Reilly Radar

Why We Use ReviewBoard For Code Reviews | Engineering Game Development

Review Board | Documentation | Users Guide

【1】ReviewBoardのリクエストを登録するには、ソースが置かれているSCMリポジトリのディレクトリとパッチ(diff)をアップロードしなくてはならない。
まずこの作業が面倒だと思った。

登録したリクエストには、パッチが差分表示されて、任意の行に指摘事項とそのコメントが自由に書ける。
画面の色も鮮やかで、UIはAjaxがバリバリ使われているので、使いやすい。

更に、リクエストにはBTSチケットNoを書くと、BTSにリンクする機能がある。
つまり、レビューと言うタスクのチケット、あるいは、レビューを受けて修正するタスクのチケットをリンクすればいい。
この機能によって、レビューのステータス管理はBTSで行えばいい。
BTSはURLを入力する形式なので、TracでもRedmineでもOK。

でも、ReviewBoardの機能には下記の不明点がある。
Review Board | Documentation | Users Guideを読むと、色々あるようだが今は分からない。

・検索機能は?
・リクエストをステータス管理できる?
・コードレビューの集計結果を表示する機能は?

【2】「ReviewBoard 釣られて使ってみた | tsuyuki.makoto」にこんな一節がある。

Tracのような感じなのかと思っていたけれど、実は全然違うものでした。
ReviewBoardは、『改変したコードを、Subversionにコミットする前に、レビューを受ける』ためのツールです。


ReviewBoardにリクエスト(パッチのレビューを受けるチケット)を登録して色々触ってみて思ったのが、上記と同じ感想だった。

これらの使い方を考えると、trunkにコミットする前に必ずレビューを受けて修正するプロセスを前提としているのが分かる。
だから、SCMリポジトリのパスとパッチ(diff)が必要なのだ。

この考え方によると、trunkにコミットする前に実装したソース、あるいは、レビューを受けて修正して再レビューを受ける前のソースは、やはりどこかにバックアップしておきたいだろう。
多分、GitやMercurialのような分散バージョン管理で別リポジトリに管理するか、trunkとは別のブランチにコミットして履歴を残すのが普通だろう。

つまり、レビューと言うプロセスはトピックブランチと相性がいいだろうと推測される。

BTSチケットをXPのタスクカードのように扱う発想がチケット駆動開発のアイデアだが、チケット駆動開発ではカバーできないプロセスとして、テスト管理(TestLink)やレビュー管理(ReviewBoard)があるのだ。

僕はTestLinkを使いこなしながら、テスト管理の奥深さを経験した。
ReviewBoardにも同様に、レビューというプロセス特有のコンテキストが隠れているように思う。


【3】GoogleがMondrianというコードレビューツールを使って、ソースの品質や設計情報の共有を図り、大きな効果をあげている現実がある。
コードレビューはとても大切だという認識を誰でも持っているにもかかわらず、実際の現場ではまともなコードレビューを行っていないのではないか?

Review Board is good software - O'Reilly Radar」を機械翻訳させると、下記のような文章になる。

しかし、良いコードレビュー(それらと同じくらい見つけにくい)は すばらしい効果を生むことができます。
あなたのコードを改良する方法を学ぶためにだれかをそれに慎重に目を通させて、1行ずつ提案をするより良いどんな道もありません。
私は慎重なコードレビューを使用するチームが、以下を報告するという結果に感動しました。
その作成は変化して、すべてがかなり清潔であって、アクセスしやすいので、コードでバグを修理するのは比較的簡単です。
かなりのコードレビューで、バグは、より浅くなります。


まだ発展途上のコードレビューツールReviewBoardには、たくさんのアイデアが詰まっているように思う。

|

« 形式手法とHaskellについてメモ | トップページ | ソフトウェアテストPRESS Vol.9にあるTestLinkの記事 »

ソフトウェア」カテゴリの記事

廃止Mercurial」カテゴリの記事

構成管理・Git」カテゴリの記事

チケット駆動開発」カテゴリの記事

コメント

いつも興味深い内容で楽しく拝見させていただいております。

私もコードレビューは大切だと思っております。

使ってみたことはないのですが、Redmineには最近Code Review Pluginというのがあるようです。
http://www.redmine.org/boards/3/topics/7646

たとえば、SubversionなどのSCMに開発用のブランチを作成し、そこで修正して、Code Reviewを実施し、必要に応じて変更した後にtrunkにマージするなどの運用をするのが良いのではないかとなんとなく考えています。

ご参考まで...

投稿: Sunday Walker | 2009/10/16 23:16

◆Sunday Walkerさん

はい、RedmineのCode Review Pluginは知ってますがまだ使ってません。
Shibuya.tracのパネルディスカッションで、Code Review Pluginを使うと簡単だがチケットがたくさんできてしまう、という質問を受けたことがあります。
それが念頭にあって、レビューはそもそもどんなプロセスが良いのか、考えるきっかけになりました。
色々試してみたいですね。

投稿: あきぴー | 2009/10/17 07:40

>だから、SCMリポジトリのパスとパッチ(diff)が必要なのだ。
今のうちのチームではこれが冗長すぎてReviewBoard諦めました

単にコードレビューって言っても、製造するソフトウェアの
性質によって最適な形態って大きく違うんですよね、うーん

投稿: TA-29 | 2009/10/17 13:52

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック


この記事へのトラックバック一覧です: ReviewBoardを使うプロセスとは?:

« 形式手法とHaskellについてメモ | トップページ | ソフトウェアテストPRESS Vol.9にあるTestLinkの記事 »