2/15/2017

Googleでのソフトウェア・エンジニアリング (2.3)

Googleでのソフトウェア・エンジニアリング」と題する論文。

2.3. コード・レビュー

Googleはメールと統合された優れたウェブベースのコード・レビュー・ツールを持っており、作者がレビューを要求し、レビュー担当者は差分(うまく色分けされて)を並べて閲覧でき、それらのコメントできる。変更の作者がコード・レビューを開始すると、レビュー担当者は変更のウェブ・レビュー・ツールのページへのリンクがメールで通知される。レビュー担当者がレビュー・コメントを投稿すると、メール通知が送信される。さらに自動化ツールは例えば自動テストの結果や静的解析ツールの調査結果を含む通知を送信することができる。

メインのソースコード・リポジトリへの全ての変更は、少なくとも一人のエンジニアによってレビューされなければならない。変更の作者が修正されるファイルの所有者の一人でない場合、少なくとも所有者の一人がレビューと変更の承認を行わなければならない。

例外的なケースでは、サブツリーの所有者はレビュー前にそのサブツリーへの緊急変更をチェックイン(コミット)できるが、それでもレビュー担当者は任命されなければならないし、変更の作者やレビュー担当者は変更がレビュー・承認されるまで、それについて自動的に表示されるだろう。このような場合、レビューのコメントに対処するため、必要となるあらゆる修正は、元の変更が既にコミットされているため、別の変更で行う必要がある。

Googleは既知の変更のためにレビュー担当者を、修正されたコードの所有権やオーナーシップ、最新のレビュー担当者の履歴、潜在的なレビュー担当者毎のコードレビューのペンディング数を検索することで、自動的に提案するツールを持っている。影響を与える各サブツリーの所有者の少なくとも一人がレビューして変更を承認しなけばならない。しかし、それとは別に、作者が適切なレビュー担当者を自由に選択できる。

コードレビューに伴う潜在的な問題の一つは、レビュー担当者の応答が非常に遅い、あるいは変更の承認に過度に気乗りしない場合は、開発を減速させる可能性がある。コードの作者がそのような問題を避けるレビュー担当者を選択する事実は、エンジニアはコードについて過度に独占したがるレビュー担当者を避ける、あるいはレビュー担当者を通してより少ないシンプルな変更のレビューを送る、より経験のあるレビュー担当者あるいは数人のレビュー担当者により複雑な変更のレビューを送る。

各プロジェクトのコードレビューの議論はプロジェクトのメンテナーによって指定されたメーリングリストに自動的にコピーされる。その変更のレビュー担当者として任命されているかどうに関わらず、コミットされた変更の前でも後でも、誰でも変更にコメントを加えることができる。もし、バグが見付かったら、そのバグを導入した変更を突き止め、元の作者やレビュー担当者がそれを認識できるよう、元のコードレビュースレッド上に間違いを指摘するコメントを行うのが一般的である。

コードレビューを複数のレビュー担当者に送信し、他のレビュー担当者がコメントする前にフォローアップの変更で取り扱われる後続のレビューコメントと共に、そのうちの誰かを承認してすぐに変更をコミットしてもらうことも可能である(もちろん、作者あるいは最初に応答したレビュー担当者のどちらかが所有者に提供される)。これによりレビューの応答時間を短縮することができる。

リポジトリのメインセクションに加えて、通常のコードレビュー要求が強制されない実験的なリポジトリがある。しかし、本番環境(production)で実行されるコードはリポジトリのメインセクションになければならない。そして、エンジニアは実験的に開発してからメインセクションに移すよりはむしろリポジトリのメインセクションでコードを開発することを強く推奨している。コードレビューは後よりむしろコードが開発された時点の方が最も効果的である。実際に、エンジニアはしばしば実験中のコードでもコードレビューを要求する。

エンジニアは個々の変更を小さく保つよう推奨している。大きな変更はレビュー担当者が簡単に一気にレビューできるよう、できれば一連の小さな変更に分けることが推奨されている1。これにより、作者が各ピースのレビュー中に提案された大きな変更に容易に対応できるようになる。非常に大きな変更はしばしば柔軟性に欠けており、レビュー担当者が提案した変更に抵抗する。変更を小さく保つ一つの方法は、コードレビュー・ツールが変更サイズの説明を付け、各コードレビューをラベル付する。30-99行の変更を追加/削除/取り除く変更は"中規模サイズ"とレベル付し、300行を超える変更はさらに批判的な(disparaging)ラベルを付けて、例えば"大規模"(300-999)、"信じられないほど巨大"(1000-1999)などとラベル付する。(しかし、通常のGoogleの方法では、毎年数日間は海賊口調日(talk-like-a-pirate day)のように、別の言い回しで親しみのある説明に置き換えることによって楽しいものになる。)


1. これはここ数年で若干変更された。コードレビュー・ツールの最新版は大きなコードレビューに対してもはや軽蔑的なラベルを使わなくなっている。しかし、それらはまだサイズで、例えば"S"、"M"、"L"、"XL"とラベル付されている。