たとえるなら
雑誌記事の校正・校閲です。書いた本人は内容を知りすぎているせいで、誤字や説明不足に気づけません。別の人の新鮮な目でチェックしてもらうことで、読者に届く前に品質がぐっと上がります。
もう少しくわしく
レビュー（コードレビュー）は、あるエンジニアが書いたソースコードを、別のエンジニアが読んで確認する工程です。バグの見落としがないか、わかりにくい書き方になっていないか、チームのルールに沿っているかなどをチェックし、問題がなければ承認されて正式にチームのコードに取り込まれます。多くの現場で、レビューを通らないコードは取り込めないルールになっています。
レビューの目的は間違い探しだけではありません。「こう書くともっと読みやすいですよ」という知識の交換や、「この部分はこういう意図です」という情報共有の場でもあります。先輩のレビューコメントは新人エンジニアにとって最高の教材ですし、逆に新人の素朴な質問がベテランの思い込みを正すこともあります。
レビューは人が人のコードを評価する場なので、伝え方の文化も大切にされています。「なぜそう書いたのですか？」と意図を尋ねる、修正案を添えて提案する、良い部分はきちんと褒める。コードへの指摘であって人格への指摘ではない、という共通認識が良いチームの土台になっています。
現場での使われ方
「このプルリクエスト、レビューお願いします」
自分が書いた変更一式を確認してほしい、という依頼。GitHubなどの画面上でコメントを付け合って進めるのが一般的です。
「レビューで指摘もらったので、直してから取り込みます」
確認者からの指摘を反映してから、正式にチームのコードに合流させる、という流れの報告です。
よくある質問
レビューは偉い人がするものですか？
役職や年次に関係なく、チームのメンバー同士で行うのが一般的です。後輩が先輩のコードをレビューすることも普通にあり、お互いの目でチェックし合うのが健全なチームとされています。