コードレビューというと、「細かい指摘をされる場」「ダメ出しされる時間」というイメージを持つ人も多いかもしれません。
ですが実際の現場では、レビューはバグ探しやマウントの場ではなく、チーム全体で品質を上げるための作業です。
では、エンジニアはコードレビューの時に、具体的にどんな点を見ているのでしょうか。
1. 正しく動くか（仕様を満たしているか）
一番大前提になるのがここです。
要件通りの挙動になっているか
仕様の勘違いや実装漏れがないか
エッジケース（想定外の入力）に弱くないか
どんなに綺麗なコードでも、仕様を満たしていなければ意味がありません。
レビューでは「このコードは正しいか？」という視点がまず最初に入ります。
2. 可読性（他人が読めるか）
レビューでとても重視されるのが可読性です。
変数名・関数名が役割を表しているか
処理の流れが追いやすいか
「なぜこの処理をしているか」が読み取れるか
コードは「自分のため」ではなく「未来の誰か（他人や将来の自分）のため」に書くものです。
一瞬で意図が伝わらないコードは、レビューで指摘されやすくなります。
3. 設計として無理がないか
次に見られるのが、設計の妥当性です。
責務が適切に分離されているか
1つの関数やコンポーネントが肥大化していないか
将来の変更に弱くない構造になっていないか
「今は動くけど、あとで地獄になるコード」になっていないか、
という視点で見られていることが多いです。
4. 同じことを何度も書いていないか
レビューでは「重複」もよく見られます。
似た処理を複数箇所に書いていないか
共通化できる部分が放置されていないか
重複が多いと、修正時にバグが生まれやすくなります。
「あとで直そう」と思っている部分ほど、レビューで拾われがちです。
5. チームのルールや文化に合っているか
コードは個人のものではなく、チームの資産です。
命名規則や書き方がチームルールに沿っているか
フォーマットが極端に崩れていないか
既存コードの流れを壊していないか
「自分はこっちの書き方が好き」という理由だけでは通らないことも多いです。
レビューではチームとしての一貫性が見られます。
6. パフォーマンスや安全性に問題がないか
すべてのレビューで必ず深掘りされるわけではありませんが、
無駄に重い処理をしていないか
セキュリティ的に危険な書き方をしていないか
データの扱いが雑になっていないか
といった点も、経験豊富なエンジニアほど自然にチェックしています。
7. 「なぜこう書いたか」が想像できるか
意外と大事なのがここです。
この実装を選んだ理由が読み取れるか
他の選択肢を検討した痕跡が感じられるか
理由が見えないコードは、「とりあえず動いたから書いた」印象を与えてしまいます。
レビューではコードそのものだけでなく、書き手の思考も見られています。
コードレビューは減点方式ではない
コードレビューは「ダメなところを探す試験」ではありません。
多くの場合、レビューする側もこう考えています。
「もっと良くするならどうするか」
「この人が次に書くコードが楽になるか」
指摘されることは、能力不足の証明ではなく、
チームの知見を共有してもらっているだけです。
おわりに
コードレビューで見られているのは、
単なる文法やテクニックだけではありません。
他人を意識して書けているか
将来を考えたコードになっているか
チームの一員として書いているか
これらが自然とコードに表れます。
レビューで指摘されたときは落ち込む必要はありません。
「自分のコードを良くするヒントをもらえた」と考えると、
コードレビューは一気に価値のある時間になります。
