Step8: コードレビューの受け方

セルフチェックが完了したら、いよいよコードレビューを依頼します。ここでは、レビュー依頼の出し方から、指摘への対応方法まで解説します。

なぜコードレビューが必要なのか

初心者あるある: 「動くんだから、そのままマージしてよ...」

flowchart TB
    A[レビューなしでマージ] --> B[バグが本番に混入]
    A --> C[読みにくいコードが蓄積]
    A --> D[チーム内で知識が共有されない]

    E[レビューを経てマージ] --> F[バグを事前に発見]
    E --> G[コード品質が維持される]
    E --> H[チーム全員が変更を把握]

レビューの目的：

• バグを早期に発見する: 本番に出る前に問題を見つける
• コードの品質を向上させる: より良い書き方を教えてもらえる
• 知識を共有する: チーム全員が変更内容を把握できる
• 学びの機会を得る: 経験者の視点を学べる

レビューで見られる観点

レビュー依頼までの流れ

flowchart LR
    A[最新ソース取得] --> B[ブランチ作成]
    B --> C[修正・動作確認]
    C --> D[セルフチェック]
    D --> E[コミット]
    E --> F[プッシュ]
    F --> G[レビュー依頼]

Gitの場合

# 1. 最新ソースを取得
git fetch origin
git checkout main
git pull origin main

# 2. ブランチを作成
git checkout -b feature/add-user-validation

# 3. 修正して動作確認（省略）

# 4. コミット
git add .
git commit -m "ユーザー入力のバリデーションを追加"

# 5. プッシュ
git push -u origin feature/add-user-validation

# 6. GitHub/GitLabでプルリクエストを作成

SVNの場合

# 1. 最新化
svn update

# 2. 修正して動作確認（省略）

# 3. コミット
svn commit -m "ユーザー入力のバリデーションを追加"

# 4. メール/チケットでレビュー依頼
#    「リビジョンXXXをレビューお願いします」

プルリクエストの書き方

基本構成

## 概要
〇〇機能を追加しました。

## 変更内容
- 入力バリデーションを追加
- エラーメッセージを追加

## 動作確認
- 正常系：〇〇を確認
- 異常系：△△を確認

## 確認してほしいポイント
- □□の実装方法は適切でしょうか
- ◇◇の命名は分かりやすいでしょうか

## 関連チケット
#123

なぜこれらを書くのか

確認してほしいポイントの例

迷った点や自信がない点は明記しておきましょう。

## 確認してほしいポイント
- この実装方法で問題ないでしょうか
- 他に良い方法があれば教えてください
- エラーハンドリングの方法は適切でしょうか

指摘を受けたときの心構え

最も重要なこと

指摘は「コード」に対するもの、「あなた」への攻撃ではない

❌ 悪い捉え方
「自分はダメだと言われた」
「否定された」

✅ 良い捉え方
「より良いコードにするためのフィードバック」
「知らなかったことを教えてもらえた」
「成長のチャンス」

防御的にならない

❌ 良くない反応
「でも仕様書にはこう書いてあったので...」
「これでも動きますけど...」
「前任者がこう書いていたので...」

✅ 良い反応
「なるほど、そういう観点がありますね。修正します」
「確かにその方が読みやすいですね。ありがとうございます」
「勉強になりました。今後気をつけます」

指摘は学びのチャンス

指摘を受けた → 新しい知識を得た → 次は同じ指摘を受けない → 成長

指摘された内容はメモして、同じ指摘を繰り返さないようにしましょう。

指摘への対応方法

パターン1: 理解できた指摘

対応: 修正して「修正しました」と返信

[レビュアーのコメント]
この変数名は userList より activeUsers の方が分かりやすいと思います。

[あなたの返信]
ご指摘ありがとうございます。修正しました。

パターン2: 理解できない指摘

対応: 質問して理解する

[レビュアーのコメント]
ここは早期リターンにした方が良いと思います。

[あなたの返信]
ご指摘ありがとうございます。
「早期リターン」について理解を深めたいのですが、
具体的にどのように変更すれば良いでしょうか？

パターン3: 納得できない指摘

対応: 建設的に議論する

[レビュアーのコメント]
この処理は非同期にすべきだと思います。

[あなたの返信]
ご指摘ありがとうございます。
非同期化については、今回の仕様では〇〇という理由で
同期処理としています。
非同期化した方が良い理由を教えていただけますか？

議論のポイント:

• 感情的にならない
• 自分の考えの根拠を説明する
• 相手の意見も尊重する
• 最終的にはチームの方針に従う

よくある指摘と対策

例: マジックナンバー

// ❌ 指摘される
if (status == 1) {
    // ...
}

// ✅ 改善後
private static final int STATUS_ACTIVE = 1;
if (status == STATUS_ACTIVE) {
    // ...
}

レビュー後の対応

1. 修正する

指摘に対応してコードを修正します。

2. コメントで返信

修正したことを伝えます。

• 「修正しました」
• 「〇〇に変更しました」

3. 再レビュー依頼

修正が完了したら、再度レビューを依頼します。

4. 学びをメモする

## レビューで学んだこと

### 2024/01/15
- 変数名は具体的に（user → activeUser）
- nullチェックは早期リターンで

### 2024/01/20
- ループ内でのDBアクセスは避ける（N+1問題）
- トランザクションの範囲を意識する

コードレビューの心得まとめ

レビュー依頼時

1. セルフチェックしてから依頼する
2. PRには背景と確認ポイントを書く
3. 動作確認済みであることを明記する

指摘を受けたとき

1. 指摘はコードへのフィードバックと捉える
2. 防御的にならず、素直に受け止める
3. 分からなければ質問する
4. 学びをメモして次に活かす

1年目の心構え

指摘が多い ≠ 能力が低い
指摘が多い = 学ぶことがたくさんある = 成長のチャンス

最初は誰でも指摘される。大切なのは、
同じ指摘を繰り返さないこと。

関連ページ

• 実装の進め方（全体像）
• Step7: セルフチェック
• Gitの基礎