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には、たくさんのアイデアが詰まっているように思う。
| 固定リンク
「ソフトウェア」カテゴリの記事
- Javaのモジュールシステムの考え方をまとめてみた(2022.10.21)
- Javaのenum型はシングルトンクラスみたいだ(2022.06.20)
- テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること(2022.02.09)
- 「RubyやRailsは終わった」という記事のリンク(2022.01.09)
- 実践した後に勉強するのがエンジニアの本来の道(2022.01.09)
「廃止Mercurial」カテゴリの記事
- GitHubはオープンソースのプロセスを標準化した(2015.06.11)
- 「反復型ソフトウェア開発」はソフトウェア工学の良書(2013.02.09)
- Mercurialに取り込まれたコミュニティ由来の機能一覧(2013.01.12)
- WordやExcelから直接Mercurialへコミットできるアドオンmsofficehg(2012.12.07)
- RedmineでSubversion リポジトリ表示を高速化する方法(2012.11.23)
「構成管理・Git」カテゴリの記事
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
「チケット駆動開発」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
コメント
いつも興味深い内容で楽しく拝見させていただいております。
私もコードレビューは大切だと思っております。
使ってみたことはないのですが、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