ソースコードレビューのベストプラクティス

はじめに

こんにちは。次世代システム研究室のT.D.Qです。

前回のエントリーでオフショア開発におけるソースレビュー事例を紹介しました。
今回のエントリーはソースレビューのベストプラクティスについて書きたいと思います。

全員共有ベストプラクティス

ソースレビューの目的を明確化

チームとプロジェクトによってソースレビューの観点が違う場合もあると思いますが、
調査の結果でいうと、ソースレビューについて以下の目的が分かりました

1.品質保障
・機能仕様がロジック上正しく実装されているかを確認するため
・不具合発見のため
・コード標準化・統一化のため
・コードの質の点で全体的なクオリティを向上させるため

2.開発者の教育
・実装者の開発力向上のため
・システム仕様の把握
・コードリーディングの技術
・コミュニケーション向上

上記の目的でチーム全員が相談し、納得した上でソースレビューを行ったほうが、
何のためにソースレビューを行うのか明確になります。

自動化

ソースレビューはできるだけ自動化しましょう。ソースレビューを支えるツールでも対応できないところ（可読性、保守性や正確性）は、人間の目で確認したほうが効率が高いと思います。コピペコードやコーディング規約違反のチェックはCIサーバーで自動的に検知できます。また、単体テストをちゃんと実装することで、ソースコードの質が向上され、ソースレビューの工数も軽減できます。

開発メンバー全員、ソースレビューに参加すべき

レビューアーのスキルレベルによって、レビューの質が変化します。チームに初心者が多すぎると、レビューしてもコードの品質は悪いままであり、スーパーエンジニアばかりのチームがコードの品質は最初から高く、いくら見ても時間の無駄である観点がありますが、実は、ソースコードレビューは、人間が目視で行うために安定せず、欠陥を見落とす可能性が高いのです。コードをよりよいものにすることと開発者のレベルアップを図るのが2の目的で、ソースレビューは「間違い探し」「犯人探し」ではなく，「参加者全員から何かを学ぶチャンスがある」といったアプローチが非常に大切だと思います。

レビューアー側のベストプラクティス

ソースコードは200～400行以内で1回のレビューにする

「The Cisco code review study」によると、400行以上をレビューすると、不具合の発見効果が激減されます。

一時間に300～500行以内レビューする

ソースレビューは速ければ速いほど良いではありません。1時間以内にソースの300～500行をレビューするのがベストです。

チェックリストを作成する

開発者にもそうですが、レビューアーに対しては、チェックリストは非常に大切なものです。
レビューアのスキル、観点に依存せず、安定した効果が期待できます。
プログラミング言語やフレームワークにベストプラクティスがあり、それを全部チェックリストにしたら、対応漏れも発見できます。
また、チェックリストを更新することで、チームの共有問題やミスが把握できるので、レビューする時、欠陥検出効率が上がります。

早期から頻繁に実施する

大がかりなレビューを少ない回数実施するのではなく、こまめな小規模レビューを繰り返す。早期から頻繁にレビューすることによって、後から大量に似たようなことを修正したりすることも避けられますし、問題の複雑化を避けることが可能になります。

心構えをレビューする

レビューアの心構えは以下の項目を挙げられます
１．議論の対象はあくまでもコード，決して開発者 になってはいけないこと。
２．物事を断定するのではなく，質問を投げかけるようにすること
３．褒めることを忘れないように
４．解決方法は1つだけではないことを念頭に
５．優先順位をつけてレビューする
ソースレビューでは、技術的な問題点に集中すべきです。開発者を評価すべきではありません。実装したソースはいろいろな事情があることと、知識として知らない可能性もあるので。
レビューアーは気づいた点を大小問わずすべて指摘するだろうが、それを全て修正する必要が必ずしもあるわけではない。修正にかけるコストと効果を勘案し、優先順位をつけて対応すれば良いと思います。

開発者側のベストプラクティス

１．コーディング規約を整備すること
２．自分用のチェックリストを更新しよう
３．コードが自分自身ではないことを忘れないように
４．積極的にソースレビューに参加
開発者は実装するとき、自分用のチェックリストを更新することで、チームの共有ミスをすぐ知っているし、そのミスを避けることが出来ます。実装するとき、コーディング規約を整備することで、ソースコードが読みやすくなります。ソースレビューする時、レビューアーがソースコードを理解する時間が短縮できます。また、開発者は自分のソースをレビューしてもらうことで、新しい技術を学ぶ良い機会が得られるので、指摘事項を積極的に受け入れることが大切です。

最後に

ソースレビューは、開発メンバー全員が参加すべきと思います。なぜなら、コードの品質を保証することと開発者を教育することの2点で有効なためです。また、ツールでソースレビューを自動化できると、チームとしても効率が上がると思います。早期から繰り返し頻繁に実施することと、心構えをレビューすることは、ソースレビューの成功ポイントだと思います。

参考URL

11 proven practices for more effective, efficient peer code review
Effective Code Reviews Without the Pain

次世代システム研究室では、アプリケーション開発や設計を行うアーキテクトを募集しています。アプリケーション開発者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ 募集職種一覧 からご応募をお願いします。

エントリー（募集一覧）

皆さんのご応募をお待ちしています。