コードレビューの実際

コードレビューは、バグを見つけたり、他のチームメンバーからインプットを得たり、知識とオーナーシップを共有するのに最適な方法だ。最大の恩恵を受けるには、コードレビューを開発プロセスに統合して、レビューされていないコードが本番環境に投入されないようにしなくてはならない。レビューは、開発プロセスにおける解決を必要とする未解決問題を明らかにするのに役立つ。

Codemotion Berlin 2018において、DevoのシニアデベロッパーであるAlex Fernandez氏がコードレビューについて語った。InfoQでは、このカンファレンスをQ&A、要約、記事で取り上げている。

オープンソースプロジェクトの大多数は外部からのコントリビューションを全てレビューしており、多くの人がチームメンバーによるコントリビューションをレビューしている、とFernandez氏は語る。しかし、ほとんどの企業では、コードを本番環境に投入する前に、誰もそのコードを読んでいない。そのコードを書いた本人ですらそうだ！ もしこの事実が恐ろしくないなら、何が恐ろしいのかわからないよ、彼は主張する。

Fernandez氏は、少なくとも作者以外の人の目でレビューされていなければ、どんなコードも本番環境に投入してはいけないという。理想的には、2、3人のレビュアーに本番環境に投入されるもの全て（些細な変更を除く）をチェックさせるのが望ましい。

コードレビューがもたらすメリットは、バグを少なくして、チームスピリットを高めることだ。また、コードのオーナーシップの共有、知識の共有、メンターシップもサポートする、とFernandez氏は語る。

コードレビューは自分を公正に保ってくれる。誰かが自分のコードをレビューするとわかっていれば、同じようにコードを書くことはないだろう、Fernandez氏は語る。

InfoQでは、コードレビューの実際についてFernandez氏にインタビューした。

InfoQ: あなたは講演で、コードレビューはソフトウェア開発で最も知られていないプララクティスの1つだと言いました。それはなぜですか？

Alex Fernandez: ほとんどの開発者は、コードレビューの大きな重要性、コードレビューをする理由、正しく実施するためのテクニック、それらがもたらす様々なメリットをわかっていません。

時々一部のコードをレビューする人はいます。でも、レビューが開発プロセスに深く浸透し、それにより潜在能力をフルに発揮できている組織を見つけるのは、非常に困難です。文献には数多くのテクニックが載っていますが、現場ではなかなか見れません。たとえば、開発者はレビューをピラミッド型の監督のように考えがちです。つまり、技術リーダーがチームのコードをレビューし、一部のシニア技術リーダーが彼らをレビューし、といった具合です。この方法でやっているプロジェクトもあります。非常に有名なのはLinux kernelです。それでも、新米デベロッパーによるレビューには独自のメリットがあります。

コードレビューに階級はありません。チームの最年長者だからといって、そのコードはレビュー不要というわけではありません。たとえ、滅多にないことですが、コードに欠陥がなくても、レビューはメンターシップとコラボレーションの機会を与え、コードベースのコード理解度のばらつきを最小限に抑えてくれます。

もう1つよくある誤解は、レビューはバグを減らすのに役立つだけであり、それを証明する確かなデータがあることです。しかし、このあと見るように、この他にも別のメリットをもたらしてくれます。

InfoQ: 何がコードレビューをそんなに重要なものにしているのですか？

Fernandez: 別の質問で答えさせてください。組織は何を本番環境にデプロイしているかわかりますか？ そのことを保証できますか？

オープンソースプロジェクトの大きな強みの1つは、まさに、コードがレビューされる頻度と激しさにあります。先ほどのLinux kernelの場合、変更はまず設計段階でレビューされ、それから初期の開発中、そして最後にサブシステムのメンテナーとその他利害関係者全員によってレビューされます。このプロセスにより、全ての変更が配布にふさわしいことを保証しています。

実際、レビュープロセスは他の全ての開発プラクティスの土台として見ることができます。たとえば、コードを個別に検査しない限り、全ての新機能にユニットテストやインテグレーションテストがあることを保証できません。オリジナルの作者以外の開発者が、全ての新機能に独自のテストがあること、またコーディング標準や読みやすさについて、手作業で確かめます。自動化ツールが役立つこともあります。テストで100%のコードカバレッジを要求するなら、TDDのようなテストプラクティスを実施してもよいでしょう。しかし結局のところ、手作業による検査の代わりはありません。テストが妥当なものであり、テストすべきものを実際に検証していることを、誰かが確かめる必要があります。

健全な報道局では、編集者のレビューなしに独自の意見を公表することは許されません。実際に、このQ&Aを書くプロセス自体、コードレビューに非常に似た気持ちを起こさせます。開発では、あるときは作者に、あるときは編集者になりますが、原則は同じです。

InfoQ: どうすればコードレビューを効果的に行えますか？

Fernandez: 最初のステップは、まず始めることです。あなたが適切だと思うやり方で、提案された変更をレビューしてみましょう。GitHubのpullリクエストやGitlabのmergeリクエストは、コードにコメントするのに最適なツールです。

次のステップは、全てのチームで定期的にコードレビューを実施することです。メリットを最大限発揮するには、コードレビューを開発プロセスに統合する必要があります。どんなコードもコードベースにマージする前に、独立したレビュアーによる承認が必要になります。以前の仕事の1つでは、Apache consensus rulesにインスパイアされて、"6つの眼" ポリシーが制定されました。変更は少なくとも、+1が2つ、-1なしのときのみマージされます。ワンライナーとパッチは+1が1つ、緊急の場合は全く精査せずにパスできます。これは非常にうまくいきました。全員が意思決定プロセスに参加していると感じ、やがて、触るのを恐れていた曖昧なコードはほとんどなくなりました。ルールは全体的なアイデアを維持しながら、より多くの（あるいは少ない）承認を要求するように調整しても構いません。誰でも変更を拒否することができ、コードを本番環境に投入するには同意を必要とします。

コードウォークスルーの実施は、長い歴史のある素晴らしいプラクティスです。オリジナルの作者とレビュアーを集めて、変更を追いかけていきます。もし作者が自分のコードを説明するだけで何も学んでいないなら、あなたは間違っています。

あなたは常に、早期にレビューし、頻繁にレビューしなくてはなりません。作者らが自分たちで何ヶ月も取り組んだためにプロジェクトが失敗するのを、私はいくつも見てきました。彼らはデリバリーできませんでした。コードレビューは、他のチームメンバーからインプットを得るのに最適な方法です。レビュアーの観点からは、指示を与えるのではなく、全てを質問にすることが重要です。たとえば、「これをこう変えて」と言うのではなく、「なぜこれが必要なのですか？」と質問するとよいでしょう。

すぐれたレビューを行うことはアートのようなものであり、それ自体、多くの相反する観点があります。あまりにも頻繁なpullリクエストは戦場やエゴ地雷をもたらします。有用である続けるためには、 正しい規律が必要です。注意: 間違ったレビュアー選びや、開発プロセスにおける遅すぎるpullリクエスト送信など、既知の落とし穴がたくさんあります。早く始めれば始めるほど、最終的により良いものが得られるでしょう。

私の経験上、あなたは辛抱強く、自然に受け入れられるまで、独立したレビューという文化を組織に浸透させる必要があります。レビューは、開発プロセスにおける未解決の問題を明らかにするのに役立つのを考慮すべきです。プロセスで見つかった問題は通常、持病のようなものです。たとえば、pullリクエストでエゴや序列が問題なら、おそらくそこに解決すべき確執があるためでしょう。

InfoQ: コードレビューはどんなメリットをもたらしますか？

Fernandez: 最初に、コンピューティングにおける聖杯を言わせてください。バグが少なくなります。これが片付くと、メリットはさらに広がります。

• コードのオーナーシップの共有: チームメンバーは、たとえ自分が書いたものでなくても、全てがどのように動くのか学びます。バス係数（bus factor）が増加します（そしてリスクが減少します）。
• 知識の共有: 上記の直接の結果として、より多くの人が、すぐれたコードを知ります。
• 責任の共有: バグが本番環境にデプロイされても、もう単独犯はいません。他の人もそれにサインしているためです。責任が小さくなるということは、もっと自信を持ってリスクのあることができることを意味します。
• チームスピリット: お互いに助け合うことは、何かをともに達成していると感じさせます。彼らはチームなのですから。やがて、pullリクエストの時だけでなく、必要な時に助けを求めることも学ぶでしょう。
• メンターシップ: 彼らのコードをレビューするだけでなく、他人のコードをレビューさせることで、新米をメンタリングするのが非常に簡単になります。
• 高い基準の維持: コードがレビューされるとわかっていると、手っ取り早い方法を取ることが少なくなります。

これらの理由で十分でければ、ひとつ悪い瞬間があってもプロダクトやチームが破滅することはない、とわかることによる安心感について考えてください。