View on GitHub

google-engineering-practices

Google's Engineering Practices Documentation Japanese Translation

コードレビューでの反対の扱い方

開発者はあなたのコードレビューに反対することがあります。一般には、あなたの提案に同意しなかったり、あなたのレビューが厳しすぎると不満を言う場合などがあります。

誰が正しいのか？

開発者があなたの提案に同意しなかったときには、初めに少し立ち止まって、開発者の意見が正しいのではないかとよく考えてください。多くの場合、レビュアのあなたよりも開発者の方がコードに親しんでいるため、コードの特定の側面についてより良い考えを本当に持っているのかもしれません。開発者の意見は意味のあるものとなっているでしょうか？ それは、コードの健康状態という観点からも意味がありますか？ もしそうならば、あなたの意見は正しかったので問題はなくなった、と開発者に伝えましょう。

しかし、開発者が常に正しいとは限りません。その場合、レビュアは、なぜ提案が正しいと信じているのかという理由を、さらに詳しく説明しなければなりません。よい説明というのは、開発者の返信に対する理解を示す言葉と、その変更が必要な理由についての追加情報の両方を含んだものです。

特に、レビュアがその提案によってコードの健康状態を改善できると信じている場合、もしコードの質の改善のために追加の作業を必要とすることを正当化できると信じるならば、レビュアはその変更を主張し続けなければなりません。コードの健康状態の改善は、小さな一歩から起こるものです。

本当に開発者の腑に落ちるまでには、数往復をかけて提案を説明しなければならないこともあります。常に丁寧に話し続けることを忘れないでください。そして、単に相手に同意するのではなく、あなたがちゃんと開発者が言っていることに耳を傾けて理解しようとしていることが伝わるように心がけてください。

開発者を怒らせる

レビュアはときに、もし今コードの改善を主張したら開発者は腹を立ててしまうに違いない、と感じることがあります。開発者が本当に怒ってしまうこともありますが、普通は腹を立てるのは短い間であり、最終的には、開発者はコードの質を改善する助けをしてくれたことをとても感謝するようになります。多くの場合、あなたが礼儀正しくコメントを書いている限り、開発者が実際には腹を立てることは全くなく、心配はレビュアの心の中で起こるだけです。開発者が怒ってしまう場合のほとんどは、コードの質についてのレビュアの主張ではなく、レビュアのコメントの書き方が原因となっています。

後できれいにする

反対が起こる主な理由は、(気持ちは理解できることですが) 開発者が作業を完了させたいと望んでいるからです。現在の CL を取り込むためだけに追加のレビューのやり取りをしたくはないのです。そのため、後で別の CL でクリーンアップをするから、この CL は今の状態で LGTM するべきだと言います。この時言ったことを非常によく守り、問題を修正するフォローアップの CL をすぐに書く開発者もいます。しかし、経験が示しているのは、開発者が元の CL を書いた後、時間が経てば経つほどクリーンアップの CL を提出する可能性も低くなってしまうという事実です。実際には、開発者が現在の CL の直後にクリーンアップを行わない場合、 クリーンアップの CL が提出されることはほとんどありません。しかしこれは、開発者が無責任だからというわけではなく、開発者にはやらなければならない仕事がたくさんあり、他の作業のプレッシャーに押されるうちに、クリーンアップの作業を見失ったり忘れたりしてしまうためなのです。だからこそ、ほとんどの場合、コードをコードベースに取り込み、作業が「完了した」とする前に、今すぐ CL をクリーンアップするように主張するのが最善なのです。

もし CL が新しい複雑さをコードにもたらすものである場合は、緊急事態でない限り、提出する前に必ずコードをクリーンアップしなければなりません。もしその CL が関連する問題を表に出すものであり、今すぐには対処できない場合には、開発者はそのクリーンアップに対してバグをファイルし、そのバグを自分自身にアサインしてください。これにより、問題が忘れられる恐れがなくなります。オプションとして、ファイルしたバグを参照する TODO コメントをコード中に書いてもよいでしょう。

厳密さに関する一般的な不満

もしあなたが以前、規律の緩いコードレビューを行っていて、その後、厳しいレビューに切り替えたとすると、非常に大きな不満の声を上げる開発者が現れることがあります。しかし、あなたのコードレビューのスピードを上げれば、多くの場合、こうした不満はだんだん解消されていきます。

このような不満の声が無くなるまでに数ヶ月もかかる場合もありますが、最終的には、優れたコードを生み出す助けとなることを理解するにつれ、開発者は厳しいコードレビューの価値を理解するようになります。時には最も激しく抵抗していた開発者でさえ、あなたが加えた厳しさの価値を本当に理解したときには、最も強い支援者になることがあります。

対立を解消する

以上のすべてに従ってもなお、あなたと開発者との間にある対立が解消できないときは、コードレビューの基準を読んで、対立を解消するのを助けるガイダンスと原則を確認してください。