意味のあるやり方をしよう。業務で使えるオープンソース（123）「ソースコードレビュー」

2008年くらいから知られるようになってきたソースコードレビューですが、一時は熱も高まったものの、そのコストがかかる割にメリットが少なかったりして次第に廃れていってしまっています。

今はGitHubなどでWebベースのコードレビューができるようになっちえます。そこで今回は改めて意味のあるソースコードレビューのやり方を考えてみたいと思います。

要点

オンラインで行う

ソースコードレビューの悪しき習慣とも言えるのが、メンバー全員が揃って行う形だと思います。ごくわずかな効果のために、全員の開発力が止まって束縛されてしまうのはデメリットが大きいのではないでしょうか。

最近ではWebベースのコードレビューも増えていますので、マージする前に必ずその機能に関わるメンバーにオンラインで目を通してもらうくらいが良いと思います。

テストをしっかり書く

動くコードをチェックするのも必要ですが、そこで分かるのは悪いコードかどうかです。これはだいたい一度か二度、その人のコードを見れば分かるのではないでしょうか。奇麗なコードを書く人が突然ダメなコードを書くケースは多くありません。

可読性高いコードであればあえて説明をうけなくとも処理内容は予想がつくはずです。むしろコードレビューでバグを見つけるのは相当大変だと思います。であればテストをしっかりと書く時間に充てる方が有益です。

仕様書を書く

それでもなお、不具合が減らないとすれば、それは仕様がちゃんと把握されていない可能性があります。APIドキュメントを書いたり、期待する動作を明文化する仕様書を適切に作る方が大事です（ソースコードが奇麗である前提です）。

バグが起きた時にレビュー

問題があるかどうか分からないコードを全て見るのは大変ですが、バグが起きているコードは必ずどこかに問題があるはずです。なのでコードレビューをマージする前ではなく、不具合が発生したタイミングで行うという手もあります。

不具合を個人の責任にするのではなく、チーム全体で把握して同じ問題が起きないように共有することでシステム全体の質を向上させていく姿勢が大事ではないでしょうか。

こまめにする

XPなどではペアプログラミングを推奨していますが、それは日々の作業時間の中でコードレビューを兼ねられるからでしょう。週に一度とかでダメ出しを食らってまとめて修正なんてのは現実的ではありません。なるべく短い時間で、少ないコードに対してレビューすべきです。

その場合、人数も最低2名からでできますし、熟練者と初級者という組み合わせであれば初級者のOJTとして考えることもできるでしょう。