誰もがすべきこと：コードレビュー

Googleコードを非常に優れたものにしている最も重要なことは、コードレビュー（以下CR）です。 CRを使用している企業はGoogleだけではありません。 これは良いアイデアであり、多くの開発者がそれを行うことは誰もが知っています。 しかし、CRがこれほど有能に実装される他の大企業を見たことはありません。 Googleでは、正のCRスコアが得られるまで、1行のコードも実稼働に入りません。

CRに注意する必要があります。 これは、ソフトウェアを深刻なレベルで開発するための前提条件です。 CRは、実稼働に入るコードだけでなく、一般的にすべてに使用する必要があります。 これはあなたが考えるほど大きな時間差ではありませんが、品質の差は大きいです。

CRを使用すると何が得られますか？

明らか：1つの頭が良く、2つの頭が良い。 実際の条件（バグ）でチェックされる前に、少なくとももう1人がコードをレビューします。 これは、CRから最も頻繁に言及される利益です。 しかし、私の経験によると、これは最も価値の低いものです。 同僚はコード内のバグを見つけますが、コードレビュープロセスで見つかったバグの大部分は、率直に言って、コード作成者が数分で見つける些細なものです。 本当に時間を費やす必要があるバグは、CRではキャッチされません。

コードレビューの最大の利点は、本質的にソーシャルです。 あなたがプログラマであり、同僚が間違いなくあなたのコードを見ると知っているなら、あなたは違った考え方をします。 コードについての意見があなたにとって重要である人々は、レビューのために送られたコードを注意深くチェックすることを知っているので、きちんとした、十分に文書化され、組織化されたコードを書きます。 CRがなければ、他の人があなたのコードを見ることも知っています。 しかし、あなたはこれがすぐには起こらないことを理解しているので、この事実はそのような潜在意識の影響を持ちません。

別の大きな利点は、知識の普及です。 多くのチームでは、個々のプログラマーがプロジェクト内で担当するコードを持ち、このプログラマーはこのコードに集中しています。 同僚がこのコードに関連する何かを破るまで、彼らはそれに注意を払いません。 これの副作用は、各コンポーネントについて、その仕組みを完全に理解している人が1人しかいないことです。 この人が締め切りに間に合わない場合、または神が禁じているために退職した場合、コンポーネントコードに精通している人は誰もいません。 コードに精通しているCRを持つ少なくとも2人のユーザー（作成者とレビューア）がいます。 レビューアは、著者が知っているようにコードを知りませんが、彼はコードの構造とアーキテクチャに精通しています。これは非常に重要です。

もちろん、これは簡単ではありません。 私の経験から、良いCRプロセスを確立するには時間がかかると言えます。 問題を引き起こす可能性のある落とし穴をいくつか知っています。 これらの石は定期的に出てきますが、CRは低いレベルにとどまりますが、負担となり、日々のワークフローでの受け入れを妨げます。

主なルールは、CRの目標は、コミットする前にコード内の問題を見つけることです。 正確さ。 初心者向けのCRの最も一般的な間違いは、コードの実行方法に基づいてコードをチェックすることです。 通常、同じことを解決する方法はいくつかあります。 さらに、コードをコードで記述する方法は数百通りあります。 レビュアーのタスクは、書かれたコードを彼が書いたように見せることではありません。いいえ-彼は決してそのようにはなりません。 レビューアのタスクは、作成者が作成したコードが正しいことを確認することです。 このルールに違反すると、感情や感情になりますが、それはあなたが目指しているものではありません。

事実、これは完全に自然な間違いです。 あなたがプログラマーである場合、コード内の問題を見ると、すぐにそれを解決する方法を見ることができ、あなたが見たのは解決策だと思います。 しかし、これはそうではありません。良いレビュアーになるには、これを理解する必要があります。

2番目に重要な落とし穴は、人々が何かを言う必要性を感じることです。 作成者がコードの作成に十分な時間と労力を費やしたことを知っているので、意見を述べる必要があるようです。

いいえ、すべきではありません。

「よさそうだ」と言っても構いません。 常に批判すべきものを見つけようとしている場合、達成できるのはあなたの権限を弱め、チーム内の関係を破ることだけです。 言いたいことを見つけるためだけにコードを批判すると、コードをチェックする人は、あなたが何かを書くためだけに書いていることを理解し、コメントは真剣に受け止められません。



3番目は速度です。 ただレビューのために送信されたコードをチェックするために実行するために真剣に取り組む必要はありませんが、一方で、あなたはそれを迅速に行う必要があります。 あなたの同僚があなたを待っています。 あなたとあなたの同僚がCRを行うのに時間をかけずに迅速に行うと、CRはチームの人々の間で不満を引き起こす可能性があります。 これは焦点の切り替えであると思われるかもしれません-CRを取り上げることです。 これは完全に真実ではありません。 新しいコードがレビューのために送信されるときにすべてをドロップする必要はありません。 しかし、数時間以内に、あなたは間違いなく何かを飲んだり、トイレに行ったり、ただ歩き回ったりします。 一時停止から戻るときは、CRに注意してください。 これを習慣にすれば、チームの誰もあなたのレビューを長時間待つことはなく、仕事に不快感を与えることはありません。

追加資料：

• Googleがコードレビューを行う方法
• あなたのようなコードレビュー