ページ

2012年11月12日

Review Board使ってみた

僕の働いている会社はハイテクとローテクが渾然一体となった訳のわからない会社です。開発プロセスでもリポジトリにコミットする前にコードレビューをしたりします。すべてのチケットでコードレビューしているわけじゃなくって、チケットや人に応じてレビューしています。コミット前のプレレビューの方法ですが、隣の人などチームの他のメンバーに「おいおい、ちょっと暇? 暇じゃなくてもコミットしたいのでレビューしてくれませんか? 答えは聞いてないけどね。」と言って強引にその場でレビューしています。

これでもコードレビュー自体はプロセスの一部となって機能しているのですが、僕にとっての不満は、現場でどういうレビューが行われているか、後からチェックできないことです。コミットの内容を見ていてレビューが十分でないと感じても、それを新たなチケットにしたりチケットをオープンしただけ(かなり後になってのレビュー)ではレビューの質が変わらないんじゃないか、と。僕がやりたかったことをまとめると


  • 現場でどういうレビューが行われいるかトラッキングしたい
  • 他人のレビューを見て学習して、レビューの全体の質が向上するかも
  • 当事者以外がもう少しレビューできる体制にしたい
システムを別途入れることで、レビューに無理矢理時間が割かれるのをどうにかしたいとか、って言う人がいるかもしれませんが、僕にとってはそれは些細な問題です。ただ、隣で説明されてレビューしていると見落としてしまうようなものも、一人でじっくりコードと向き合うことでレビューの質が高まるという効果はあるかもしれません。

BTSのTracを使っているので最初はTracのプラグインを検討したんですが、コミット後のレビューがほとんどです。アリエルの開発スタイルからはプレコミットレビューがいいですが、少なくとも僕の要望ではプレでもポストでもどちらでもいいです。で、まとめてレビューを一覧したり、レビューごとにどのように実際のコードが変化するかとか終えないです。専用のシステムの方が細かく見られます。

と言うことで、Review Boardを導入しました。アリエルだとEclipse派とコマンドライン派がいます。Eclipse派はEclipseのプラグインeReviewBoardを使っています。ただ、このeReviewBoardはsubclipseを要求します。subversiveの方が便利なので悲しい決断です。でもほとんどの人にとってsubclipseでもsubversiveでも同じような気がするんですが・・・。
コマンドライン派がpost-reviewコマンドを使っています。そしてコマンドライン派はgit svnを使っているので、gitへのcommitで自動でReview Boardにポストさせています。

一週間使ってみてやりたかったことができそうだったので、とりあえずは満足です。大きな不満もおじさんになってしまったakayaman以外からは出ていないのでまあ、いいんでしょう。と言うか、数人からなる一つのチームだけで始めるつもりがみんな勝手に使っている・・・。

0 件のコメント: