ストーリー

コードレビューとは何か

コードレビューとは、他の開発者に自分のコードを確認してもらう作業です。

graph TD
    S1["あなたがコードを書く"] --> S2["PRを出す"]
    S2 --> S3["レビュアーがコードを確認"]
    S3 --> S4["コメント・指摘・質問をもらう"]
    S4 --> S5["修正・対応する"]
    S5 --> S6["承認（LGTM）→ マージ"]

LGTM = “Looks Good To Me”（良さそうです）という承認の意味

レビューの目的

1. バグの早期発見

他の人の目で見ることで、自分では気づかないバグを発見できます。

あなた: 「完璧にできた！」
レビュアー: 「この条件だとnullになりませんか？」
あなた: 「...あ、本当だ」

2. コードの品質向上

より良い書き方やベストプラクティスを学べます。

レビュアー: 「この処理、配列のfilterメソッドを使うともっと簡潔に書けますよ」
あなた: 「なるほど、そういう方法があるんですね！」

3. 知識の共有

チーム全員がコードの内容を理解できるようになります。

レビュアー: 「この設計の意図を教えてもらえますか？」
あなた: 「この部分は将来の拡張を考慮して...」
→ チーム全体の理解が深まる

4. 一貫性の維持

チーム全体で統一されたコードスタイルを保てます。

レビューは攻撃ではない

新人がレビューで最も勘違いしやすいことがあります。

レビューの本質

レビューは「あなたの敵」ではなく「あなたの味方」

× レビュー = 試験 = 採点される場
○ レビュー = 協力 = 一緒に品質を高める場

レビューで指摘される内容の種類

レビューの文化

良いチームのレビュー文化：

よくあるレビューコメントの例

良いコメントの例:
「ここは○○にするとパフォーマンスが改善すると思います。
 参考: https://...」

「Nit: インデントが1箇所ずれています」
（Nit = 些細な指摘という意味）

「質問: このロジックの背景を教えてもらえますか？」

「Nit」は “nitpick”（些細なこと）の略で、軽微な指摘を意味します。

新人にとってのレビューの価値

レビューは最も効率的な学習機会の1つです。

レビューで学べること:
- コードの書き方のベストプラクティス
- チームのコーディング規約
- 設計の考え方
- エッジケースの考慮方法
- 先輩の知識と経験

指摘が多いということは、それだけ学びが多いということ。 レビューを「怖いもの」ではなく「成長のチャンス」と捉えましょう。

まとめ

チェックリスト

• コードレビューの目的を4つ挙げられる
• レビューが「攻撃」ではないことを理解した
• 指摘の種類（バグ、改善、質問、スタイル、設計）を理解した

次のステップへ

コードレビューの概要が理解できましたか？

次のセクションでは、レビューを受ける前の準備について学びます。 良い準備をすることで、レビューがスムーズに進みます。

推定読了時間: 30分