LESSON 30分

コードレビューとは

ストーリー

PRを出したら、先輩から「レビューコメント」がたくさん付いていた。

「うわ...ダメ出しばかり...自分はやっぱりダメなのかな...」

「そうじゃないよ。レビューはダメ出しじゃない。品質を上げるための協力作業なんだ」

「協力...ですか?」

「そう。レビューの正しい理解から始めよう」


コードレビューとは何か

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

[あなたがコードを書く]
    ↓
[PRを出す]
    ↓
[レビュアーがコードを確認]
    ↓
[コメント・指摘・質問をもらう]
    ↓
[修正・対応する]
    ↓
[承認(LGTM)→ マージ]

LGTM = "Looks Good To Me"(良さそうです)という承認の意味


レビューの目的

1. バグの早期発見

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

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

2. コードの品質向上

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

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

3. 知識の共有

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

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

4. 一貫性の維持

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


レビューは攻撃ではない

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

勘違い事実
「ダメ出しされた」品質を上げるための提案
「自分の能力を否定された」コードへのフィードバック(人格否定ではない)
「完璧にしないとダメだ」最初から完璧な人はいない
「指摘が多い=ダメな開発者」指摘が多い=学びが多い

レビューの本質

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

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

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

種類対応
バグの指摘「この条件だとエラーになりませんか?」修正する
改善提案「こう書くともっと読みやすくなりますよ」取り入れる
質問「この処理の意図を教えてください」説明する
スタイル「命名規則に合わせましょう」修正する
設計「この責務はこのクラスに含めるべきでしょうか」議論する

レビューの文化

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

特徴説明
建設的問題だけでなく解決策も提案する
敬意がある丁寧な言葉遣いで指摘する
学びの場指摘を通じてチーム全体が成長する
双方向レビュアーもレビューを受ける人から学ぶ

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

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

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

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

「Nit」は "nitpick"(些細なこと)の略で、軽微な指摘を意味します。


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

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

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

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


まとめ

ポイント内容
コードレビューとは他の開発者にコードを確認してもらう協力作業
目的バグ発見、品質向上、知識共有、一貫性維持
本質攻撃ではなく、品質を高めるための協力
新人にとっての価値最も効率的な学習機会

チェックリスト

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

次のステップへ

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

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


推定読了時間: 30分