レビュープロセスを効率化するには？

ReviewBoardとコードレビューに関するメモ。

【元ネタ1】オンラインコードレビュー支援ツール「Review Boad」

これまで自分がやっていたソースコードのレビューは紙に印刷して、赤ペンでガリガリ書いていくというスタイルだったので、ちょっと目から鱗でした。そんな感じでコードレビューをやっていくと手間がかかる割には、使い終わった後はゴミ箱に捨てられていたりしたわけですが、これを使うとレビュー結果が蓄積されていくので便利ですよね。
そう考えると初等プログラミング教育用としても使うのも面白いのかなと思っています。先生をやっていて、その辺りが一番やりきれない部分だったので。。。。

昔も今もコードレビューする場合、大量の紙を印刷して、赤ペンでガリガリチェックするのが普通だろう。
パソコン上で差分表示しながらレビューしてもいいが、レビューコメントを残したりするのが面倒だから。
モニタでは目が疲れる理由もある。

コードレビューやデザインレビューは、20年前の机上デバッグの頃と何ら進歩していない状況と言えるのではなかろうか？
だからこそ、ReviewBoardでコードレビューをWeb化する利点がある。

【元ネタ2】ReviewBoard: 雲の亀日記

雲は、ソフトウエアの開発では情報の共有が最も重要だと思っています。
ここで言う情報とは、仕様書とか機能のことではなくて、どちらかといえば、暗黙の知識・経験といったことを意図しています。その一つとして、開発者個人が持っている暗黙知の共有としてのコードレビューに高い意義があると個人的には感じています。ただ、現状のコードレビューにはその効果が全く無い（←極論）と思っていて何とかならないものかと、つねづね考えていました。
で、忙しいくせについついそういうことを検索していると、ReviewBord というものに行き当たりました。これは、素晴らしい。これを使うと、コメントとソースコードがリンクしてくれるので、後から見直すのも楽だし、修正方法も明確に理解できる。こういうシステムを導入することで、生産性は飛躍的に向上しそうな感じがします。
生産性向上には、プロセス以外のファクターの要素も絡んでいることが多くのマネージャーにもっと理解されるようになると良いですね。

ソフトウェア開発では、暗黙知の共有が重要とよく言われる。
その理由は、仕様や設計、アーキテクチャなどの情報はExcelや紙などの媒体だけでは、メンバーに伝わらないから。

何故そんな汚いパッチが付けられたのか？
何故そんな修正が発生したのか？

コードレビューは単なる欠陥探し、あら探しではなく、メンバー同士で暗黙知を共有し合う場でもある。
コードレビューはXPのペアプロの代替手段なのだ。

【元ネタ3】「ピアレビュー」を読みました ― ありえるえりあ

3章に「インスペクション」、「レビュー」、「ウォークスルー」の比較表があります。
誰が定義したんだ、と言いたくなる比較表で、この定義に従う必要性は感じませんが、この3つの用語、日常の中であまりに曖昧すぎて何を指しているのか分からないのも事実です。
比較表を見る限り、モデレータ、作成者、読み手の役割の部分が明らかな相違です。

* インスペクション: モデレータ、作成者、読み手を、それぞれ別の人が行う。
* レビュー: インスペクションとウォークスルーの中間形態(モデレータと読み手が一致する場合など)。
* ウォークスルー: 作成者がモデレータかつ読み手を兼ねる。

コードインスペクションをしていて思うのが、本当は、デバッガで動的にコードを追いながらコードを見る方が効率的だろうな、という思いです。
デバッガを使わず、頭の中だけでコードを動かしてバグを見つけられる自分のスキルを誇らしく思う気持ちは、正直に告白すれば、あります。
しかし、自分のささやかなプライドを満たすことがコードインスペクションの目的ではありません。

レビュープロセスは、プログラミングやテストとはプロセスが異なる点に注意すべき。
最も厳格なプロセスがインスペクション、中間がレビュー、プライベートっぽいプロセスがウォークスルー。

ウォークスルーは、IT勉強会でよく行われている形式だろう。

レビューで必要な役割は、プログラミングやテストの場合と異なる。
レビューでは、モデレータ・作成者・読み手・記録者の4つの役割がある。

普通は、レビューの形式が多いだろう。
つまり、レビューアがモデレータ、レビューイが作成者・読み手・記録者を兼ねる。

このプロセスの欠点は、レビューアやレビューイの負担が大きい。
レビューイは、レビューで指摘された内容を記録し、理解し、修正したのを再チェックするプロセスが曖昧になりがち。
レビューアは、たくさんのレビューイからレビューが寄せられて、開発プロセスのボトルネックになる。

しかし、インスペクションをいつも開催するのは工数がかかりすぎる。
普通は、インスペクションは優先順位の高い成果物に絞って行ったり、レビューの進捗管理に注意を払ったりする。

BTSを導入してタスク管理や進捗管理を効率化できたり、TestLinkを導入してテストの進捗管理を効率化できたように、レビューもツールを導入して効率化できないのだろうか？

【元ネタ4】Karl E. Wiegers著『ピアレビュー』日経BPソフトプレス、2004.3.1、2900円（税別）、＜高品質ソフトウエア開発のために同僚同士で行うレビュー＞

・ピアレビューはすべて、「計画、作業成果物の準備、レビューミーティング、エ
ラーの修正、修正の検証」の５つのアクティビティの何らかの組み合わせです。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
ピアレビューの種類 　　計画 　準備 　ミーティング 　修正 　検証
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
インスペクション 　　　　○ 　　 ○ 　　 ○ 　　　　　　　○ 　　　○
チームレビュー 　　　　 ○ 　　 ○ 　　 ○ 　　　　　　 ○ 　　 ×
ウォークスルー 　　　　 ○ 　　 × 　　 ○　　　　　　 ○ 　　 ×
ペアプログラミング 　　 ○ 　　 × 　　 継続的 　　　　○ 　　 ○
ピアデスクチェック、 　 × 　　 ○ 　　可能 　　　　　 ○ 　　 ×
パスアランド
アドホックレビュー 　　 ×　　 × 　　 ○ 　　　　　　 ○ 　　 ×
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

レビューにも色んな種類がある。
最も効果があると言われるインスペクションを行う為に必要なノウハウを書いている本が『ピアレビュー』。

レビュープロセスは、おそらく20年前から何も進化していない。
レビューがシステムの品質改善に有用であると誰もが理解しているのに、徹底できない理由は、プロセスの運用に壁があり、プロセスを効率化できていないからだ。
何とかならないのだろうか？？

ここ5年間で、開発環境だけでなくプロジェクト管理を巡る環境が急激に変化している。
RailsやPHPで簡単にWebシステムを作れるようになってから、タスク管理・進捗管理・テスト管理・バージョン管理が急激に進化している。
チケット駆動開発もこの流れの上にのっている。

レビュープロセスもこの流れの延長線上で、運用のハードルを下げるべきだ。