コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第42回　Googleのソフトウェア開発におけるコードレビューの役割

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第42回　Googleのソフトウェア開発におけるコードレビューの役割 (中井悦司) 2018年7月

はじめに

　今回は、2018年に公開された論文「Modern Code Review: A Case Study at Google」をもとにして、Googleのソフトウェア開発におけるコードレビューのプロセスを紹介したいと思います。Googleでは、オープンソースの開発で広く用いられる、変更リスト（Change List:CL）単位の軽量なコードレビュープロセスを採用しており、この論文では、1回のレビューにおけるコードの変更量や平均的なレビュアー数についての興味深い統計データも紹介されています。

コードレビュープロセスの概要

　Googleのソフトウェア開発におけるコード変更のプロセスについては、第20回の記事を参考にしてください。ソフトウェア開発者は、リポジトリ上のソースコードをローカルのワークステーションに（仮想的に）クローンした後に、ローカルでコードの修正を行います。その後、修正部分についてのコードレビューを経て、リポジトリに対するコミット（変更の反映）が行われます。

　一般に、ソフトウェア開発のコードレビューにはいくつかのスタイルがあり、たとえば、「コードインスペクション」と呼ばれる手法では、ソフトウェアのすべてのソースコードを最初から最後まで人間の目でチェックして、その動作を論理的に検証していきます。このような徹底的なレビュー手法については、学術的には一定の有効性が認められているものの、一般的なソフトウェア開発の現場では、時間と手間がかかりすぎるという理由で、それほど広く普及することはありませんでした。オープンソース・ソフトウェアを始めとする多くのソフトウェア開発においては、コードの変更部分を中心にレビューツールを用いてコメントをやり取りする、ややインフォーマルな手法が広く用いられています。

　Googleでは、オープンソースのレビューツールであるGerritに類似のツールを用いてレビューが行われています。図1は、Gerritのスクリーンショットですが、このように、コードの変更部分についてレビュアーと開発者がコメントをやり取りしながら、コードの再修正などを行っていきます。基本的には、一般的なオープンソースと同様のレビュープロセスと考えてよいでしょう。

図1 Gerritのスクリーンショット（Gerritのホームページより引用）

コードレビューの目的

　それでは、そもそもGoogleにおいて、コードレビューを行う目的は何なのでしょうか？　現在のコードレビューのプロセスを導入した、初期のGoogleの社員によると、「他の開発者が理解できるコードを書かせること」が、その目的だそうです。言い換えると、コードをレビューするレビュアーは、コードを見てその動作がすぐに理解できない場合は、時間をかけてそのコードを分析する義務はありません。そのコードを書いた開発者に対して、もっと理解しやすいコードを書くように要求することができるのです。そして、この結果として、次のような効果が生まれることになります。

コードの保守性が向上する
意図しない不具合の混入が防止される
新しいプロジェクトメンバーがレビューを通じてコードへの理解を深める
他のチームによるコードの利用を容易にする

　図2は、冒頭の論文に記載されている図ですが、ここには、開発者とその他のメンバーの間に、コードレビューを通じて生まれる関係性が示されています。この図からもわかるように、コードレビューに参加するのは、該当プロジェクトのメンバーだけとは限りません。レビューを依頼する開発者は、有益と思われる任意のレビュアーを自由にアサインすることができます。ただし、最終的にコミットする上では、プロジェクトオーナーのLGTM（「Looks good to me」の略で了承を表すメッセージ）が必須となります。

fig02

図2 コードレビューを通じた、開発者とその他のメンバーの関わり

コードレビューに関わる統計データ

　ここで最後に、論文内で紹介されている、Googleにおけるコードレビューに関する統計データを紹介します。これは、2014年1月から2016年7月にかけて行われた9百万個のCL（Change List: 1回のコミットに含まれる一連の修正のセット）に対するレビューデータにもとづくもので、主なポイントには、次のようなものがあります。

90%のCLでは、変更されるファイル数は10個以下
35%のCLでは、1つのファイルのみ変更

1つのCLで変更が入る行数は、中央値で24行
10%のCLでは、1行のみの変更

99%のCLでは、レビュアーは5人以下
75%のCLでは、レビュアーは1人

レビュアーのアサイン後、小さな変更で1時間、大きな変更で約5時間以内にレビューコメントを受け取る
1人の開発者は、平均して週に3時間のコードレビューを実施

　この結果を見ると、Googleのコードレビューは、予想以上に「軽量」であると感じられるかも知れません。一般的なオープンソースの開発と比較しても、1回のコミットにおける変更はより小さく、より短い期間でレビューが完了している点が論文の中でも指摘されています。小さな変更を頻繁に行うことで開発効率を向上するという、現代的な開発プロセスの考え方が反映された結果と言えるかも知れません。

次回予告

　今回は、2018年に公開された論文「Modern Code Review: A Case Study at Google」をもとにして、Googleのソフトウェア開発におけるコードレビューのプロセスを紹介しました。「他人が理解できるコードを書く」こと、すなわち、コードの可読性を確保する点については、一般にもその重要性がよく指摘されます。Googleのコードレビューは、まさにコードの可読性を高めることが最大の目的というのは、なかなか興味深い点と言えるでしょう。

　次回は、コードレビューに関連する話題として、プログラムコードの静的チェックツールに関する話題をお届けしたいと思います。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡