ソースレビューの結果は文章にして共有して欲しいこれだけの理由
ウチでは昔から新規、修正された全ソースに対してソースレビューを実施している。これ自体は特に珍しいことではなく、やってるとこはやってることだと思う。ソースレビューと書いたが、仕様レビュー、結合テストレビューを含める。
レビューすべき内容
レビューでチェックするのは、ざっと、以下のような点かなと思う。
(1)要件に合致しているか
仕様レビューで指摘するべき
(2)漏れがなく、重複が無いか
結合テストレビューで指摘するべき
(3)バグ等が無いか
様々なレイヤでの原因が考えられるため、仕様、結合テスト、ソースのすべてのレビューで指摘が発生する。
(4)デグレードが無いか
これも上記と同様
(5)運用上の懸念点が無いが
これも上記と同様
(6)パフォーマンス上の懸念は無いか
仕様、ソースレビューで指摘するべき
(7)コーディング規約上の違反事項は無いか
ソースレビューで指摘するべき
（指摘優先順位順）。
レビューは会議室でやる場合もあれば、レビューボード等のレビュー用ツールを使用したり、「見といてください」形式だったりするだろうが、形式は何でもソースレビューをいかなる形式で実施しようともレビュー結果は文章で残し、その指摘点は後から閲覧、検索できるようにして欲しいなと思う。
文章で残して共有するメリット
上記の観点からチェックしたのかどうか、した場合、どのような指摘が出たのか、指摘に対してどのように対処したのか、を文章で残して欲しいのだ。文章に残すことによって以下のメリットがある。
(1)適切なレビューがなされているのか、後から確認が出来る
どんなレビューであっても「レビューした」という証拠残しにはなるのかもしれないが、実質的に重要なのは質の高いレビューがなされたか、ということだ。文章で残すことで当然そのことが後からある程度客観的に観測できる。問題の多かったプロジェクトはレビューの質の低さと相関は無いか？といったことが代表的な活用方法だろう。
(2)上記のことからレビューの緊張感・集中力が高まる
最も大きい効能かもしれないが、レビューの出席者も後から確認できるため、出席者はいい加減な態度や指摘は出来なくなる。場当たり的な指摘も出来なくなるし、出席者以外の人間もレビューの内容を把握できるため、「密室での裁判」のようなレビューも防げるように思う。
(3)修正の経緯が後からわかり、仕様の理解の助けとなる
どのような経緯でこのような仕様に落ち着いたのか、後からはなかなかわかりにくいことがある。仕様書というのは結論にあたる部分だけが記述され、そこに行き着くまでの歴史は一切割愛されてしまう。結論だけ見ても、仕様が理解できなかったり、曲解したり、見落としたりすることは多い。
(4)どのような指摘が過去になされたか、共有できる
技術者というのは出入りがあるため、新しい人が入るたびに実は同じような指摘をされているはずなのだが、それがナレッジとして残るようになる。新しい人は過去の指摘を見ればある程度どのような指摘があるのか事前に把握することが出来るし、優秀なレビュアーの指摘は見ているだけでも勉強になるだろう。実際、優秀なレビュアーのちょっとした一言に雷に打たれるような経験をしたことは私も多い。この経験が「使い捨て」られているのは勿体無いだろう。
