LESSON 30分

レビューを受ける準備

ストーリー

「レビューお願いします！」

「...えーと、このPR、説明文が何もないけど、何を変更したの？」

「ログイン機能を直しました！」

「どう直したの？なぜ直したの？テストは？」

「...」

「PRを出す前に準備が必要だね。レビュアーの時間を大切にしよう」

なぜ準備が大切か

レビュアーはあなたのコードを理解するところから始めます。

準備なしのPR:
レビュアー: 「何が変わったんだろう...」（理解に30分）
→ レビュアーの時間を無駄にする
→ 的外れな指摘が増える
→ やり取りが増える

準備ありのPR:
レビュアー: 「なるほど、この変更の意図がわかった」（理解に5分）
→ レビュアーが本質的な指摘に集中できる
→ 効率的にレビューが進む

準備1: セルフレビュー

PRを出す前に、自分自身でコードをレビューします。

セルフレビューの手順

1. git diff でコード差分を確認する
2. 「他の人が見たらどう思うか」の視点で読む
3. チェックリストで確認する
4. 不要な変更（デバッグコード等）がないか確認する

セルフレビューのチェックポイント

確認項目具体例
不要な変更が含まれていないか関係ないファイルの変更が混ざっていないか
デバッグコードが残っていないかconsole.log、debugger等
コメントは適切か不要なTODO、古いコメントがないか
テストは書いたか/実行したか変更に対応するテストがあるか
変更が大きすぎないか1つのPRに複数の変更を詰め込んでいないか

自分で見つけられる問題は、自分で直してからPRを出すのがマナーです。

準備2: PR説明文を書く

レビュアーがPRを理解するための説明文を書きます。

PR説明文のテンプレート

markdown
## 概要
このPRで何をしたか（1〜2行）

## 変更内容
- 変更点1
- 変更点2
- 変更点3

## 変更の理由
なぜこの変更が必要だったか

## テスト
- どのようにテストしたか
- テスト結果

## スクリーンショット（UI変更がある場合）
変更前と変更後の画面

## 関連チケット
チケットへのリンク

良い例と悪い例

悪い例:

markdown
ログイン修正

良い例:

markdown
## 概要
ログイン時のバリデーションエラーメッセージを改善しました。

## 変更内容
- エラーメッセージを「ログインに失敗しました」から
  「メールアドレスまたはパスワードが正しくありません」に変更
- パスワード入力欄をエラー時にクリアするように変更
- バリデーションのテストケースを3件追加

## 変更の理由
ユーザーから「エラーメッセージが分かりにくい」との
フィードバックがあったため（チケット #123）

## テスト
- 既存の単体テスト: 全てPASS
- 追加した3件のテスト: 全てPASS
- 手動テスト: Chrome、Firefoxで動作確認済み

## 関連チケット
#123

準備3: 変更の意図を明確にする

「何を変えたか」だけでなく、「なぜ変えたか」を伝えることが重要です。

コードコメントで意図を伝える

javascript
// × 意図が不明
if (retryCount > 3) {
  return;
}

// ○ 意図が明確
// APIの利用規約により、リトライは最大3回までに制限
if (retryCount > 3) {
  return;
}

PRの説明で意図を伝える

markdown
## なぜこのアプローチを選んだか

案A: データベースにキャッシュする
案B: メモリにキャッシュする ← 採用

理由: 現時点ではデータ量が少なく、
メモリキャッシュで十分なパフォーマンスが得られるため。
データ量が増えた場合はデータベースキャッシュに移行を検討。

準備4: 適切なサイズに分割する

大きなPRはレビューの質が下がります。

PRのサイズレビュー品質目安
小（〜200行）高品質なレビュー理想的
中（200〜400行）まずまずのレビュー許容範囲
大（400行〜）雑なレビューになりがち分割を検討
× 1つのPRに全部入れる:
  - ログイン機能の修正
  - 新しいAPIの追加
  - CSSの調整
  - テストの追加
  → レビュアー:「...多すぎて見れない」

○ 分割する:
  PR1: ログイン機能の修正
  PR2: 新しいAPIの追加
  PR3: CSSの調整
  → レビュアー: 各PRに集中してレビューできる

PR提出前チェックリスト

markdown
## PR提出前チェックリスト

### セルフレビュー
- [ ] git diff で変更内容を自分で確認した
- [ ] 不要な変更（デバッグコード等）を削除した
- [ ] 関係ないファイルの変更が含まれていない

### テスト
- [ ] テストを実行し、全てパスした
- [ ] 変更に対応するテストがある

### PR説明文
- [ ] 何を変更したか書いた
- [ ] なぜ変更したか書いた
- [ ] テスト結果を書いた
- [ ] 関連チケットをリンクした

### サイズ
- [ ] PRが適切なサイズに収まっている（目安: 400行以下）

まとめ

ポイント内容
セルフレビュー自分で見つけられる問題は自分で直す
PR説明文概要、変更内容、理由、テスト結果を記載
変更の意図「何を」だけでなく「なぜ」を伝える
適切なサイズ大きすぎるPRは分割する

チェックリスト

  • セルフレビューの手順を説明できる
  • PR説明文に含めるべき内容がわかる
  • 変更の意図を伝える重要性を理解した

次のステップへ

レビューを受ける準備が理解できましたか？

次のセクションでは、実際にレビューコメントを受けたときの対応方法を学びます。 コメントへの返し方、修正の仕方を覚えましょう。

推定読了時間: 30分