コードレビュー

一言でいうと

書いたコードを別の開発者が読み、欠陥や設計上の問題を見つける工程です。欠陥の検出は自動化のほうが速く、人が読む価値は設計の判断のほうにあります。

提唱者と登場年

体系的に研究され記述された最初の形式は、Michael Faganが提唱したInspectionです。1976年にIBM Systems Journalで発表されました。複数の参加者で役割を決め、手順に沿って詳細に検査する形式的なプロセスです。

現在の実務で行われているのは、これを大幅に軽量化したものです。バージョン管理サービスの変更依頼に対して非同期でコメントを付ける形が主流で、国内でも標準的な工程になっています。国内での普及時期を裏づける一次データは持っていないため、年としては示しません。当時の論文は購読が必要で本文を確認できないため、出典には書誌情報が追えるページを置いています。

何を解決するか

書いた本人には見えない前提の誤りを、別の視点で検出します。加えて、実装の意図をチームに共有する場としても働きます。レビューを通すことで、その領域を読める人が最低2名になります。

欠陥の検出だけが目的であれば自動化された検査のほうが速く、確実です。人が読む価値は、設計の判断と、なぜその形にしたのかの部分にあります。

実際の進み方

変更を小さく分けて依頼を出し、担当者が読んでコメントを返します。指摘は、修正が必須のものと、提案にとどまるものを区別して書きます。区別がないと、受け手はすべてを必須と解釈するか、すべてを無視するかのどちらかに寄ります。

形式の指摘は自動化に任せます。整形と静的解析で機械的に検出できる内容を人が指摘すると、レビューの往復が増えるだけになります。

導入でよくある失敗

• 変更の粒度が大きい。読む負荷が上がり、承認だけの通過儀礼になります
• 承認者を1人に固定する。その人が滞留の原因になります
• 指摘の強度を示さない。受け手が優先順位を判断できません

求人票にこの語がある場合に読み取れること

いまはほとんどの組織が実施しているため、あること自体は情報になりません。読み取れるのは、記述の具体性です。レビューの基準や承認の条件まで書かれている場合、工程として設計されていると考えられます。

媒体の検索には使えず、要件に書いても差はつきません。

自社側では、変更が承認されるまでの平均的な時間を確認します。1営業日以内なら回っている状態で、数日から1週間かかっていれば滞留です。候補者には、指摘をどう書いていたかを聞きます。修正が必須のものと提案を区別できる人は、レビューを工程として理解しています。

隣接手法との違い

関連キーワード

ペアプログラミング / テスト駆動開発 / 静的解析 / プルリクエスト