プルリクエストが大きいときにコードレビューを改善するにはどうすればよいですか？

免責事項：同様の質問がいくつかありますが、大規模なプルリクエストのレビュー中に直面する問題に特に関係する質問は見つかりませんでした。

問題

私のコードレビューはもっと良い方法でできると思います。特に、20以上のファイルに多くの変更が加えられた大きなコードレビューについて話している。

明らかなローカルコードの問題をキャッチするのは非常に簡単です。ただし、コードがビジネス基準を満たしているかどうかを理解することは別の話です。

コード作成者の思考プロセスに従うのに苦労しています。変更が多数あり、複数のファイルに分散している場合は非常に困難です。特定の変更に関連するファイルのグループに焦点を当てようとしています。次に、グループを1つずつ確認します。残念ながら、私が使用しているツール（Atlassian Bitbucket）はあまり役に立ちません。私がファイルにアクセスするたびに、現在確認されている変更の一部に関連していないことがよくありますが、ファイルは表示済みとしてマークされます。言うまでもなく、一部のファイルは複数回アクセスする必要があり、それらの変更は個別にレビューされます。また、悪いパスをたどったときに関連するファイルに戻るのは簡単ではありません。

可能な解決策、およびなぜそれらが私にとってうまくいかないのか

コミットによってプルリクエストを確認することでサイズの問題を解決できることがよくありますが、古い変更を頻繁に見ているので、私はそれが好きではありません。

もちろん、より小さなプルリクエストを作成することは改善策のように見えますが、それが何であるか、時には大きなプルリクエストを取得し、それをレビューする必要があります。

また、コード全体の論理的な側面を無視することもできますが、特にコードが経験の浅いプログラマーのものである場合は、かなりリスクが高いようです。

より良いツールを使用することは役立つかもしれませんが、私はそれを見つけませんでした。

ご質問

• コードレビューで同様の問題がありますか？どのように彼らに直面しますか？
• たぶんあなたはより良いツールを持っていますか？

私たちはこれらの問題を抱えており、以下の質問をすることは私たちにとってうまく機能しています。

PRは、マージして個別にテストできる1つのことを行いますか？

単一の責任（SR）でPRを打破しようとします。最初のプッシュバックの後、人々は、単一であるにもかかわらず小さなものでさえ大きくなる可能性があることに気付いて驚いた。

SRを使用すると、レビューが非常に簡単になり、予想される実装に関する知識が広まります。

これにより、追加のリファクタリングも可能になり、PRの所要時間が大幅に短縮されます！

可能であればSRでそれらを分割することをお勧めします。そのようにするための練習が必要です。

大量のプルリクエストを避けることができない場合もありますが、誰がどのような責任を負っているのかを見極めることができます。

私はプルリクエストを説得力のある引数として扱います。著者は、コードがこのように見えて動作するはずだと私に納得させようとしています。

他の引数と同様に、明確なアイデアが1つ必要です。そのどちらか：

• リファクタリング、
• 最適化、
• または新しい機能。

明確でない場合は、自分で理解していない可能性がかなりあります。対話を開き、彼らの議論をそのサブ引数に分解するのを助けてください。必要に応じて、完全に大丈夫です-それらのコミットを再作成し、より包括的で直接的なプルリクエストを提供することも有益です。

引き続き大きなプルリクエストがありますが、明確な引数を使用すると、適合しないものを簡単に確認できます。

ツールに関しては、組織とプロセスに依存します。BitBucketは、予算、ハードウェア、要件から、既存のプロセス、ビジネスルール、およびBitBucketに対応するためにすでに行ったさまざまなソフトウェアの適応に至るまで、すべてが優れているかどうかに左右されます。動作を設定できるかどうかをドキュメントで確認し、プラグインコミュニティに投げ出す（または、プラグインを作成して参加させる）ことから始めます。

完全なプルリクエストを確認するのではなく、すべてのコミットを確認してください。この方法でプルリクエストを理解することができます。¹

コミットが小さい場合、そのようなレビューを行うことは問題になりません。コミットを通じて1つずつ変更を追跡し、全体像を把握します。いくつかのコミットを後で取り消す変更を時々レビューするなどの欠点がありますが、これは大したことではないはずです。

コミットが大きい場合は、それらのコミットを行った人と話し合う必要があります。大規模なコミットに問題がある理由を彼に説明してください。他の人がめったに変更をコミットしない理由についての議論に耳を傾けてください。たとえば、コミット前のフックに時間がかかりすぎるため、コミットを避けることを知ることができます。その場合、この問題を最初に解決する必要があります。

コミットによってプルリクエストを確認することでサイズの問題を解決できることがよくありますが、古い変更を頻繁に見ているので、私はそれが好きではありません。

あなたはそうしますが、これは小さな問題であり、単一のファイルをレビューするときにコードが変更された理由を理解しようとするよりも数回のコミットを取り消すコードをレビューする時間をはるかに少なくする必要があります。

「頻繁に」はあいまいですが、プルリクエストの最終リビジョンに到達しなかったコードを確認するのに時間がかかりすぎる場合は、次の2つの方法を使用できます。

• コミットメッセージを読むだけで、すべてのコミットをすばやく1回実行します。このようにして、特定のコミットを検討する際に、後からコミットメッセージが表示されている変更が元に戻されたことを言ったことを覚えているかもしれません。

• ファイルの最新バージョンを並べて表示します（多くの場合、大規模なコミットでは、（1）ファイルが根本的に異なる可能性があり、（2）ファイルの名前が変更されるか、コードの大きなブロックが他の場所に移動して、一致するファイルを見つけにくくします）。

• 理にかなっているときにコミットを破棄するようコミッターに依頼するか、あるコミットが別のコミットの一部を元に戻す特定のコミットメッセージ規則を設定し、いくつかの後続のコミットを考慮してレビューを行います。

^{¹たとえば、変数の名前が変更されたファイルを見ているとします。それはあなたに何を伝えますか？この変更をどのように確認する必要がありますか？ただし、コミットによってコミットを確認している場合、1つのコミットで20個のファイルの同じ変数の名前が変更され、適切なビジネス用語を使用するために名前が変更されたことがコメントに示されます。この変更は完全に理にかなっており、確認することができます。}

プルリクエストのレビューで達成しようとしていることを解決し、代替手段があるかどうかを確認します。

たとえば、あなたがしたいことがあります

• 基準が守られていることを確認する
• チェック機能が正しい
• 複数の人がコードを理解していることを確認してください
• ジュニアを訓練する

などなど

これらのいくつかは他のものによってよりよく役立つかもしれません、そして、理由を理解するだけであなたのチェックの範囲を制限することができます。

たとえば、トレーニングのために変更を提案したり議論したりできるようにすべての行をチェックしている場合は、シニアが行う大規模なPRでそれをスキップできます。

コードを理解する必要がある場合は、大規模な機能でペアプログラミングを行い、コードレビューを標準チェックに限定することをお勧めします。

QAへの階層化されたアプローチがある限り、すべてのPRですべてをチェックする必要はありません。