結論：指摘の8割は「読みやすさ」と「設計の浅さ」
バグや動作不良の指摘より、可読性・命名・責務分離の指摘が圧倒的に多いです。 逆に言えば、ここを意識するだけでレビュー回数が劇的に減ります。
言われた指摘TOP10
変数名・関数名が分かりにくい
「data2 って何のデータですか？」
「data」「temp」「result」のような曖昧な名前が多発。意図が伝わる名前（userPaymentList など）を付ける癖を意識するだけで激減。
関数が長すぎる
「この関数100行ありますね...分けましょう」
1関数1機能の原則を意識。20〜30行を超えたら分割を検討する習慣をつけました。
マジックナンバーがある
「この86400って何の数字ですか？」
定数化（SECONDS_PER_DAY = 86400）して意味を持たせる。コメントで補うより定数化の方が読みやすい。
例外処理が雑（catchで握り潰す）
「except: pass はやめてください」
例外を握り潰すと、後で原因不明のバグになります。最低でもログに残す習慣を。
ネストが深すぎる
「if文4階層は読みづらい」
早期return（ガード節）で浅くする。3階層を超えたら設計を見直すサインです。
コメントが「何をしているか」しか書いていない
「コメントは『なぜ』を書いてください」
「i に 1 を足す」ではなく「翌日の日付を計算するため +1 する」のように意図を書く。
テストが無い・少ない
「正常系だけじゃなく異常系も書きましょう」
「動いたから完成」ではなく「期待通り動くことを保証するテスト」までがセット。
同じコードがコピペされている（DRY違反）
「3箇所同じ処理ですね、共通化しましょう」
2回出てきたら共通化を検討。3回出てきたら必ず共通化する習慣を。
不要なコメントアウトが残っている
「このコメントアウト要りますか？削除しましょう」
「あとで使うかも」のコメントアウトはほぼ使いません。Gitに履歴があるので削除でOK。
1コミットの粒度が大きすぎる
「1コミットに10ファイル変更されてます...」
「1コミット1目的」を意識。レビューする側の負担が激減し、自分の作業整理にもなります。
これらは『リーダブルコード』を読むだけで7割は事前に学べます。新人時代に最も読んで良かった本です。
レビューを乗り越えるためのコツ
- セルフレビューしてから提出する（自分で粗探し）
- Lint・Formatter を必ずかけてからPRを出す
- 「なぜこの実装にしたか」をPR説明文に書く
- 指摘内容はメモしておき、二度と同じ指摘を受けない努力をする
- レビューは「人格否定」ではなく「コードの改善」と切り離して考える
まとめ：指摘は「成長の機会」
コードレビューで指摘を受けるのは、最初は心が折れます。 でも振り返れば、あの指摘の積み重ねが今のコードを支えています。 「指摘を成長の機会」と捉えると、レビューが楽しくなります。