コードレビューとは
ストーリー
PRを出したら、先輩から「レビューコメント」がたくさん付いていた。
「うわ...ダメ出しばかり...自分はやっぱりダメなのかな...」
「そうじゃないよ。レビューはダメ出しじゃない。品質を上げるための協力作業なんだ」
「協力...ですか?」
「そう。レビューの正しい理解から始めよう」
コードレビューとは何か
コードレビューとは、他の開発者に自分のコードを確認してもらう作業です。
[あなたがコードを書く]
↓
[PRを出す]
↓
[レビュアーがコードを確認]
↓
[コメント・指摘・質問をもらう]
↓
[修正・対応する]
↓
[承認(LGTM)→ マージ]
LGTM = "Looks Good To Me"(良さそうです)という承認の意味
レビューの目的
1. バグの早期発見
他の人の目で見ることで、自分では気づかないバグを発見できます。
あなた: 「完璧にできた!」
レビュアー: 「この条件だとnullになりませんか?」
あなた: 「...あ、本当だ」
2. コードの品質向上
より良い書き方やベストプラクティスを学べます。
レビュアー: 「この処理、配列のfilterメソッドを使うともっと簡潔に書けますよ」
あなた: 「なるほど、そういう方法があるんですね!」
3. 知識の共有
チーム全員がコードの内容を理解できるようになります。
レビュアー: 「この設計の意図を教えてもらえますか?」
あなた: 「この部分は将来の拡張を考慮して...」
→ チーム全体の理解が深まる
4. 一貫性の維持
チーム全体で統一されたコードスタイルを保てます。
レビューは攻撃ではない
新人がレビューで最も勘違いしやすいことがあります。
| 勘違い | 事実 |
|---|---|
| 「ダメ出しされた」 | 品質を上げるための提案 |
| 「自分の能力を否定された」 | コードへのフィードバック(人格否定ではない) |
| 「完璧にしないとダメだ」 | 最初から完璧な人はいない |
| 「指摘が多い=ダメな開発者」 | 指摘が多い=学びが多い |
レビューの本質
レビューは「あなたの敵」ではなく「あなたの味方」
× レビュー = 試験 = 採点される場
○ レビュー = 協力 = 一緒に品質を高める場
レビューで指摘される内容の種類
| 種類 | 例 | 対応 |
|---|---|---|
| バグの指摘 | 「この条件だとエラーになりませんか?」 | 修正する |
| 改善提案 | 「こう書くともっと読みやすくなりますよ」 | 取り入れる |
| 質問 | 「この処理の意図を教えてください」 | 説明する |
| スタイル | 「命名規則に合わせましょう」 | 修正する |
| 設計 | 「この責務はこのクラスに含めるべきでしょうか」 | 議論する |
レビューの文化
良いチームのレビュー文化:
| 特徴 | 説明 |
|---|---|
| 建設的 | 問題だけでなく解決策も提案する |
| 敬意がある | 丁寧な言葉遣いで指摘する |
| 学びの場 | 指摘を通じてチーム全体が成長する |
| 双方向 | レビュアーもレビューを受ける人から学ぶ |
よくあるレビューコメントの例
良いコメントの例:
「ここは○○にするとパフォーマンスが改善すると思います。
参考: https://...」
「Nit: インデントが1箇所ずれています」
(Nit = 些細な指摘という意味)
「質問: このロジックの背景を教えてもらえますか?」
「Nit」は "nitpick"(些細なこと)の略で、軽微な指摘を意味します。
新人にとってのレビューの価値
レビューは最も効率的な学習機会の1つです。
レビューで学べること:
- コードの書き方のベストプラクティス
- チームのコーディング規約
- 設計の考え方
- エッジケースの考慮方法
- 先輩の知識と経験
指摘が多いということは、それだけ学びが多いということ。 レビューを「怖いもの」ではなく「成長のチャンス」と捉えましょう。
まとめ
| ポイント | 内容 |
|---|---|
| コードレビューとは | 他の開発者にコードを確認してもらう協力作業 |
| 目的 | バグ発見、品質向上、知識共有、一貫性維持 |
| 本質 | 攻撃ではなく、品質を高めるための協力 |
| 新人にとっての価値 | 最も効率的な学習機会 |
チェックリスト
- コードレビューの目的を4つ挙げられる
- レビューが「攻撃」ではないことを理解した
- 指摘の種類(バグ、改善、質問、スタイル、設計)を理解した
次のステップへ
コードレビューの概要が理解できましたか?
次のセクションでは、レビューを受ける前の準備について学びます。 良い準備をすることで、レビューがスムーズに進みます。
推定読了時間: 30分