回答:
私の経験では、ほとんどの正式なコードレビューは簡単であるため、スタイルチェックに発展します。見るべきもののチェックリストを提供するときでさえ、目がグレージングし始めることはかなり簡単です。
ユニットテストのレビューにはより多くの利点があることがわかりました。私が一緒に働いたほとんどの開発者は、適切に単体テストを行う方法を本当に知りません。コードの残りの部分も同様に改善し始めます。ヒントを次に示します。ユーザーに何かを検査するように要求する場合は単体テストではなく、デバッガーで実行するために何かを開始するだけの場合は単体テストではありません。
問題の内容によって異なる傾向があります。多くの場合、それは単純なゴム印です。「ここに問題がありました。この行を見てください。何が間違っているのかは明らかです。ここで修正しました。」「はい、それはかなり明白です。先に進み、チェックインしてください。」
しかし、もっと複雑なことが起こっている場合、通常は次のようになります。
開発者がレビュアーと一緒に座って、コードを1行ずつ説明するコードレビューを好みます。多くの場合、開発者は、レビュー担当者がまだ見たことがないかもしれないという説明を行う際に問題が発生するため、これが私の好みです。また、コードを送信して自分で読んでコメントを書くコードレビューも行いますが、それらは時間がかかる傾向があると思います戻って説明し、2、3ラウンド後に説明し、画面上で私が意味することと開発者が言うことを指摘します。「ああ、ええ、今見ています。」）さらに、「あなたはこれを間違っていました。」
また、コードレビューで標準を実施することも重要ですが、それらを唯一の焦点にすることはできません。
ただし、コードレビュー担当者が満足するか、マネージャー（開発者ではない）が彼または彼女を却下する（コードレビュー担当者も間違っている）まで、コードはプロダクションに送信されません。これは非常に重要です。コードレビューは、プッシュされる前にコードレビュー担当者が最終コードを承認する必要がない限り、付加価値のない単なる官僚的なプロセスです。
まず、コーディング標準が必要です。これらは単なる構文ではありません。あなたの会社で仕事を始めるとき、彼らはコーディングを始める前にあなたの会社のガイドラインをできるだけ学ばなければなりません。レビュープロセスですべての種類の違反が見つかった場合、次のようになります。
ガイドラインは理にかなっており、違反を見つけてできるだけ簡単にリファクタリングするための適切なツールが必要です。ガイドラインの目標とコードレビューを常に確認する
私の頭の中の目標は、コードを可能な限り均一にし、保守性と読みやすさの問題を見つけることです。副次的な目標は、特定のソフトウェアでより多くの人々を最新の状態にすることです。
私の心の中のガイドラインは、たとえば次のものから成り立っています。
これを実施すると、コードレビューは、ガイドラインに照らしてチェックされるソフトウェアと以下から構成されます。