【Googleに学ぶ】コードレビューを円滑に進める「４つの極意」

コードレビュー。コードの品質向上のために大事な作業。でも、

そう思うエンジニアは、けっこう多いです。

コードレビューでは、レビューする側とされる側、個々の考えがしばしば対立します。時には、人格否定めいた発言で感情的なあつれきが生じることさえも。

どうすれば、うまく円満にレビューを進められるのでしょう？

この問題に対して、Googleが、コードレビューの在るべき姿を示しています。

• 適正なレビューとはなにか？
• レビューをどう進めるべきか？

世界のGoogleに、コードレビューの極意を学びましょう。

不満が渦巻くコードレビュー

まずは、なぜこんなにもコードレビューに不満が生じるのか？整理しましょう。

コードレビューの目的

コードレビューとは、つまりこんな作業です。

• ある人が書いたコードを
• 別の人がチェックして修正点を指摘する

その目的は、集約するとこの２つ。

このうち、不具合を解消する、というのは分かりやすい。そりゃ直さなきゃいけないでしょう。

不満が出るのは、たいていこっち、読みやすいコードにする。

正解のないレビュー？

読みやすいコードにするという考えから、レビューする側は、こんな指摘を行ったりします。

この指摘に対して、レビューを受ける側はこんな気持ち。

こういう、両者の想いのすれちがいが起こりがち。

それはつまりこうでしょう。読みやすいコードという定義には正解がないから。お互いの信じることが違えば、意見がすれ違い続けます。

Googleが示すコードレビュー指針

このように、すれ違いが起こりがちなコードレビュー。そのやり方に対して、Googleがひとつの回答を示しています。

コードレビューはどう行うべきか

Googleが“Google Engineering Practices Documentation”という資料を公開しています。その中で、コードレビューの指針についての記事があります。

Googleが示すコードレビュー指針は、単なる表面上のテクニックではありません。根底にある重要な考え方が示されています。

Googleコードレビューのポイント４つ

要約すると、重要なことは以下の４つ。

それぞれ見ていきましょう。

完璧ではなくとも「改善された状態」なら承認する

コードレビューを行うとき、最も悩む問題がこれ。

「レビューをいつ終わらせるか？」

読みやすさなんて、いくらやってもきりがない。ゴールがない。頭を悩ませる問題です。

そのときの考え方がこれ。

そのコードが完璧でなくとも、コードが改善されている状態なら、承認する。

これが、Googleコードレビューガイドラインの中で、最も上位となる原則とされています。

完璧なコードは存在しない

このガイドラインの源泉にあるのは、プログラマーなら誰しも気づいている、この重大な事実です。

• 完璧なコードなど存在しない

だからレビュー担当者は、コードの隅から隅まで磨き上げるような要求をすべきではありません。

完璧などない。そこにあるのは、前回よりも改善されたコードだけ。

であれば、前より改善が見られたなら承認をして、とにかく先へ進むのです。

継続的に改善することを意識する

コードレビューで大事にすべきは、継続的な改善です。完璧ではないという理由で、レビューを先延ばしにしてはいけません。

レビューの単位を小さくし、即時に承認。これを繰り返していくのです。

個人の好みより「技術的な事実」を優先する

コードには、書いた人の個性が滲み出ます。

プログラミングが上達すると、洗練した書き方を覚えるし、色々なことを試したくなります。この程度差が異なると、意見がぶつかることになります。

そこで、この考えが大事になります。

個人的な意見や好みよりも、技術的な事実とデータを優先する。

基礎となる原則に基づく

実は、ソフトウェア設計においては

• 純粋なスタイルや、単なる個人的な好みは、ほとんど問題になりません

ソフトウェアには、様々な原則があります。そしてソフトウェアは、基本的にはそれらに基づいて評価されるべきです。

アプローチが複数あり、同等に有効であるならば、好みを受け入れることも可能です。

しかしアプローチについて、それを選択する理由が存在するなら、標準原則に基づいて決定されるべきです。

一貫性を保つ

では、原則に当てはまらない場合はどうするか？

そうであったとしても、個人的な好みで勝手に決めることは、できるだけ避けるべきです。

重要なのは、一貫性です。ソフトウェア全体で、統一感のある書き方を定義して守るべきです。

技術的指針を決めておく

ソフトウェアの書き方がばらつく理由のひとつとして、個々人の知識の差があります。

開発を始めたての新人と、数十年の経験を持つベテランとでは、書き方は異なるでしょう。それでも、ばらつきは出来るだけ抑えるべきです。

このようなときは、バイブルとする指針を決めておくとよいです。

• 書籍の知識
• Webサイトの知識
• スタイルガイド

レビューする側される側、両者が、そのバイブルに則って、コードレビューを進めていきます。

誰が正しいのかではなく「何が正しいのか」を議論する

コードレビューでの大きな不満の原因となるのが、指摘の仕方。例えその指摘が誤りでないとしても、大きな不満が生じるときがあります。このような事態をどう避けるべきか？

この問題への、Googleの回答がこれです。

人物を批判しないこと。指摘には人物に関する見解を含めないこと。

問題は、品質のこだわりより指摘の仕方

コードの複雑さを指摘したいとき、こんな指摘をする人がいます。

言っていることは正しかったとしても、こういうな指摘は、感情的な対立を招きます。

そのコメントが人物に関するものと認識されると（たとえば、「あなたは」や「あなたの」という言葉）、コードを改善するという目標から注意をそらしてしまいます。

改善する対象は、人物ではなくコードです。コードに対する指摘をしましょう。

あくまで、コードに内在する問題について話し合うよう、意識しましょう。

指摘にはフィードバックが必要

指摘には、具体的かつ実用的なフィードバックも必要です。

なんて指摘だけでは、どうしていいか分かりません。

その指摘によって、改善に向けた行動が取れる必要があります。

また、決定を下した理由も添えると、より指摘が明確になります。

レビュー指摘は「翌日まで」に回答する

感情的な対立を避けるため、意外と気付きにくい、大事なこと。

それは、すぐに回答するということです。Googleはこのように言っています。

コードレビューリクエストへの応答は、最大でも 1 営業日（つまり、翌朝一番）に回答する。

待ち時間が不満を募らせる

とある開発者が、コードレビューをお願いしたとき、

• レビュー担当者の回答が、依頼から１週間経ってから
• しかもその指摘で、大幅な変更が要求されている

こうなると、開発者のイライラは、急上昇します。

多くの場合、こういうときの苦情は、「レビューの指摘が厳し過ぎる！」と表されます。

でもこれ、同じ変更内容であっても、迅速に回答したときは、苦情が消える傾向があります。

コードレビュープロセスに関する苦情のほとんどは、プロセスを高速化することで実際に解決されるのです。

すぐに返答する

コードレビューの回答は、早ければ早いほど効果があります。可能な限りすぐに着手しましょう。

とはいっても、他の仕事が輻輳してさばききれない場合も、あるでしょう。

そうだとしても、なにかしらの回答は翌日までに出すのです。何かしらのレスポンスがあることが、不満の発生を大きく抑制します。

まとめ

コードレビューという作業は、人によっても、場所によっても、時間によっても、やり方は異なってきます。

なかなか定型的にできる作業ではありません。それが故に、考え方の違いが顕著に出る作業です。

でも、意見の違いは出て当たり前。

レビューする側もされる側も、コードの健全性を向上したいという想いは同じはず。

建設的な対話を心がけましょう。