Google はどのようにコードレビューを行っていますか? コードレビューから何が得られますか?

この記事は海外雑誌IT Reviewより翻訳されたものです。原文リンクはこちら。

私はもうGoogleで働いていません。まだどこに行くかは決まっていませんが、目の前にはとても良い仕事のチャンスが 2、3 つあります。この意思決定期間中、私は誰にも雇われていなかったので、何か専門的なこと、興味深いこと、そして同僚や経営陣との緊張関係を生むようなことを書けると思いました。

Google は非常に優れた会社です。彼らは、社外の人々の目に触れるところでも、社内でも、多くの素晴らしいことを成し遂げました。社内では機密事項ではないが、社外では十分に議論されていない事柄がいくつかあります。今日はそれについてお話ししたいと思います。

Google のプログラムを非常に優れたものにしている最も重要な要素の 1 つは、一見単純なコード レビューです。これを行っているのは Google だけではありません。コードレビューは良い習慣として広く認識されており、多くの人が行っています。しかし、これほど大規模で、これほど幅広くこのようなものを使用できる会社は他に見たことがありません。 Google では、効果的なコードレビューを行わずに、プログラム、製品、プロジェクト コードをコード ベースに送信することはできません。

すべてコードレビューを経ます。そして、これは公式です。この種のことは、あらゆる真剣なソフトウェア開発作業における基本的な経験則であるべきです。製品プログラムだけでなく、すべてです。多くの労力はかかりませんが、その効果は絶大です。

コードレビューから何が得られますか?

当然のことですが、バグが入り込むのを防ぐために、提出する前に別の人にコードをチェックしてもらいましょう。これは、コードレビューの利点に関する最も一般的な理解であり、最も広く認識されているものです。しかし、私の経験では、これは最も重要でない点です。コードレビューではバグが見つかることもあります。しかし、コードレビューで発見されるバグのほとんどは、プログラム作成者が数分で見つけられるような些細なものであることは明らかです。実際に発見に時間のかかるバグは、コードレビューでは見つかりません。

コードレビューの最大の利点は、純粋に社会的なものです。プログラミングをしていて、同僚がコードをチェックすることを知っている場合、プログラミングに対する姿勢はまったく異なります。あなたが書くコードは、より簡潔になり、コメントが適切になり、構造もより良くなります。なぜなら、あなたが大切に思っている誰かがあなたのプログラムを見ていることがわかっているからです。コードレビューがなければ、結局は人々があなたのコードを見ることになるのは明らかです。しかし、それはすぐに起こることではなく、同じ緊急感を与えるものではなく、同じ個人的な判断の感覚を与えるものでもありません。

もう一つ非常に重要な利点があります。コードレビューは知識を広めます。多くの開発チームでは、各人がコアモジュールを担当し、全員が自分のモジュールにのみ集中することがよくあります。同僚のモジュールが自分のプログラムに影響を与えない限り、同僚同士が通信することはありません。この状況の結果、各モジュール内のコードに精通しているのは 1 人だけになります。もしその人が休職したり、最悪の場合辞めてしまったりしたら、誰にもどうすることもできません。コードレビューでは、作成者とレビュー担当者の少なくとも 2 人がプログラムに精通している必要があります。レビュー担当者はプログラムの作成者ほどプログラムを理解することはできませんが、プログラムの設計とアーキテクチャについては精通しており、これは非常に重要です。

もちろん、何も簡単にできるわけではありません。私の経験では、コードレビューを適切に実行できるようになるまでには、コードレビューを学習する時間がかかります。コードレビュー中にミスを犯す人が多く、それが多くのトラブルにつながることがわかりました。特に、経験の浅いレビュー担当者は、コードレビューで悪い経験をさせることが多く、それがコードレビュー システムを受け入れる妨げになります。

最も重要な原則: コード レビューの目的は、コードが送信される前にコード内の問題を見つけることです。つまり、コードが正しいかどうかを確認することです。コードレビューで最もよくある間違い、つまりほぼすべての初心者が犯す間違いは、レビュー担当者が自分のプログラミング習慣に基づいて他の人のコードを判断することです。

問題に対しては、通常、それを解決するための方法が 12 個以上見つかります。解決策としては、それを実装するためのコーディング スキームが何百万も考えられます。レビュー担当者として、レビュー対象のコードが自分のコーディング スタイルに従っているかどうかを確認するのは仕事ではありません。自分が書いたコードと同じになる可能性は低いからです。コードレビュー担当者のタスクは、作成者が記述したコードが正しいことを確認することです。この原則が破られると、あなたは苦痛とフラストレーションを感じることになりますが、それは私たちが望む結果ではありません。

問題は、この間違いが非常に一般的であり、簡単に起こってしまうことです。プログラマーであれば、問題に遭遇したときに解決策を考え、考えた解決策を標準的な答えとして使うことができます。しかし、そうではありません。優れたレビュアーになるには、そのことを理解する必要があります。

コードレビューでよくある 2 番目の落とし穴は、人々が何かを言わなければならないというプレッシャーを感じてしまうことです。作者がこれらのプログラムの実装に多大な時間と労力を費やしたことはご存じのとおりです。これは何かを物語っているのではないでしょうか。

いいえ、必要ありません。

「わあ、それはいいですね」とだけ言うのは決して不適切ではありません。常に批判する何かを見つけようとすると、結局は自分の名誉を傷つけるだけになります。ただ何かを言うためにわざわざ何かを探すと、検閲されている人は、あなたがただ沈黙を埋めるためにそれを言っているだけだと分かるでしょう。あなたのコメントは今後は真剣に受け止められません。

3つ目はスピードです。コードレビューを急ぐことはできませんが、迅速に実行できることも必要です。仲間があなたを待っています。あなたや同僚がコードレビューにあまり時間をかけたくないために、すぐに終わらせてしまうと、レビュー担当者は不満を感じてしまい、このようなコードレビューは失望をもたらすだけです。それはまるで全員の邪魔をして、作業を中断させてレビューを強制するようなものです。こんなはずじゃなかった。コードレビューを行うために、今行っている作業をすべて中断する必要はありません。しかし、旅行に数時間かかる場合は、休憩をとったり、お茶を飲んだり、シャワーを浴びたり、しばらくおしゃべりしたりする必要があります。レビューサイトに戻ったら、先に進んで作業を完了できます。あなたがこんな状態なら、誰もそこで待っていてくれないと思います。

scientopia経由

元のタイトル: Google はどのようにコードレビューを行っていますか? コードレビューから何が得られますか?

キーワード: Google、コードの書き方、レビュー、コード、レビュー、何が手に入るか、この記事、ウェブマスター、ウェブサイト、ウェブサイトのプロモーション、お金を稼ぐ