これでもコードレビュー自体はプロセスの一部となって機能しているのですが、僕にとっての不満は、現場でどういうレビューが行われているか、後からチェックできないことです。コミットの内容を見ていてレビューが十分でないと感じても、それを新たなチケットにしたりチケットをオープンしただけ(かなり後になってのレビュー)ではレビューの質が変わらないんじゃないか、と。僕がやりたかったことをまとめると
- 現場でどういうレビューが行われいるかトラッキングしたい
- 他人のレビューを見て学習して、レビューの全体の質が向上するかも
- 当事者以外がもう少しレビューできる体制にしたい
システムを別途入れることで、レビューに無理矢理時間が割かれるのをどうにかしたいとか、って言う人がいるかもしれませんが、僕にとってはそれは些細な問題です。ただ、隣で説明されてレビューしていると見落としてしまうようなものも、一人でじっくりコードと向き合うことでレビューの質が高まるという効果はあるかもしれません。
BTSのTracを使っているので最初はTracのプラグインを検討したんですが、コミット後のレビューがほとんどです。アリエルの開発スタイルからはプレコミットレビューがいいですが、少なくとも僕の要望ではプレでもポストでもどちらでもいいです。で、まとめてレビューを一覧したり、レビューごとにどのように実際のコードが変化するかとか終えないです。専用のシステムの方が細かく見られます。
と言うことで、Review Boardを導入しました。アリエルだとEclipse派とコマンドライン派がいます。Eclipse派はEclipseのプラグインeReviewBoardを使っています。ただ、このeReviewBoardはsubclipseを要求します。subversiveの方が便利なので悲しい決断です。でもほとんどの人にとってsubclipseでもsubversiveでも同じような気がするんですが・・・。
コマンドライン派がpost-reviewコマンドを使っています。そしてコマンドライン派はgit svnを使っているので、gitへのcommitで自動でReview Boardにポストさせています。
一週間使ってみてやりたかったことができそうだったので、とりあえずは満足です。大きな不満もおじさんになってしまったakayaman以外からは出ていないのでまあ、いいんでしょう。と言うか、数人からなる一つのチームだけで始めるつもりがみんな勝手に使っている・・・。
0 件のコメント:
コメントを投稿