私の経験では、社内のほとんどのチームが、常に数百行未満の少量のコードでチームメンバーのコードを確認しています。コードが完成し、一度にすべてのレビューを受ける準備ができたときに、モジュールなどの大量のコードをレビューすることは適切ですか？
回答:
小さなコードレビューの理由は、効果を最大化するためです。
パーソナルソフトウェアプロセスに関する調査では、1時間あたり150〜200行以下のコードのソースをレビューする場合、レビュー担当者がレビューで特定された欠陥を最大化することに関して最も効果的であることがわかっています。その経験的データを考えると、人々が注意深く滞在できる時間を決定することが問題になります。経験的なデータはありませんが、何かを読んでから約1時間後に心が動き始めます。私にとって、これはコードレビューで一度に150行未満のコードをレビューする必要があることを示しています。
チームがより良い製品を作成するのに役立つかどうかは適切です。
コードレビューが小さいチャンクに焦点を合わせることが多いいくつかの理由：
大量のコードを適切に確認するには、各参加者が準備に非常に長い時間を費やす必要があり、コストがかかる可能性があります。
レビュー会議が長くなるほど（実際にはどの会議でも）、注意を払う人が少なくなります。2時間はほとんどの人が立つことができる程度の時間であり、会議をそれよりも短い時間（たとえば、1時間または90分のトップ）に保つことは、全員が最高の状態であることを確認するための長い道のりです。
多くの場合、すべての行を確認する必要はありません。コードを確認する1つの理由は、全員が基本的に同じコーディングガイドラインのセットに固執していることを確認することです。少量のコードの詳細なレビューは、多くのコードの詳細なレビューよりも、その目的に適しています。
とはいえ、より多くのコードをレビューすることが役立つとわかった場合、そしてチームがそれに耐えられる場合は、ぜひ試してみてください。いくつかの基本的なルールと、進行中の会議を続けるためのファシリテーターとして行動する誰かがいることを確認するのに役立ちます。また、レビュー担当者に事前にコメントを送信してもらい、空白の不適切な使用などの細かいことに費やす時間を減らし、重要で興味深い問題について話し合う時間を増やすことを検討してください。
既に完了している（おそらく機能している）大量のコードを確認すると、「修正して変更する...」ではなく、「実行すべきだったはずです...」というセッションに変わります。
したがって、アクティビティの主な目的が死後の学習課題である場合、大規模なコードレビューは理にかなっています。欠陥を見つけようとするのであれば、おそらくあまりうまくいきません。レビューの全員が退屈で疲れているため、小さな欠陥は見落とされる可能性が高く、大きな構造上の欠陥は、「今では遅すぎる-コードが作成され、顧客が昨日それを望んでいる」ため、スキップされる可能性があります。