<CodeLearn/>
コードレビュー レッスン2

良いPRの書き方

レビューしやすいPull Requestを作成するテクニックを学ぼう

PRタイトルの書き方

PRタイトルは、何を変更したかが一目で分かるように書きます。 多くのチームではConventional Commitsに似たプレフィックスを使います。

プレフィックスの種類

feat: 新機能
fix: バグ修正
refactor: リファクタリング
docs: ドキュメント
style: スタイル修正
test: テスト追加
chore: 雑務
perf: パフォーマンス改善
ci: CI/CD変更

良いタイトルの例

  • feat: ユーザープロフィール編集機能を追加
  • fix: ログインページのバリデーションエラーを修正
  • refactor: UserService のDB接続処理を共通化

悪いタイトルの例

  • 修正 - 何を？
  • update files - どのファイルを？なぜ？
  • WIP - 内容が全く分からない

PR説明文テンプレート

レビュアーが素早くコンテキストを理解できるよう、What / Why / How / Testingの4点を必ず記載しましょう。

## What（何を変更したか）
ユーザープロフィール編集画面を新規作成しました。
名前、メールアドレス、プロフィール画像の変更が可能です。

## Why（なぜこの変更が必要か）
Issue #123 の対応。ユーザーからプロフィール編集の要望が多数あり、
MVP機能として実装しました。

## How（どのように実装したか）
- ProfileEditForm コンポーネントを新規作成
- useProfile カスタムHookでAPI通信を管理
- 画像アップロードには presigned URL を使用

## Testing（テスト方法）
- [ ] プロフィール名の変更が反映されることを確認
- [ ] バリデーションエラーが表示されることを確認
- [ ] 画像アップロード後にプレビューが表示されることを確認
- [ ] 既存のユニットテストが全てパスすることを確認

## スクリーンショット
（UI変更がある場合はここに添付）

チームへの導入方法

GitHubでは .github/PULL_REQUEST_TEMPLATE.md に テンプレートを配置すると、PR作成時に自動で反映されます。

小さなPR vs 大きなPR

PRのサイズはレビューの質に直結します。 大きなPRほどレビューが雑になりがちで、バグが見逃されやすくなります。

小さなPR（推奨）

  • • 変更行数: 200行以下が目安
  • • 1つの論理的な変更に集中
  • • レビューが速い（15-30分）
  • • フィードバックが具体的になる
  • • コンフリクトが起きにくい

大きなPR（避けるべき）

  • • 変更行数: 500行以上
  • • 複数の機能が混在
  • • レビューに数時間かかる
  • • 「LGTM」で済まされやすい
  • • マージ後の問題特定が困難
# 大きな機能を小さなPRに分割する例

# PR 1: データモデルとDBマイグレーション
feat: プロフィールテーブルにavatarUrlカラムを追加

# PR 2: バックエンドAPI
feat: プロフィール画像アップロードAPIを実装

# PR 3: フロントエンドUI
feat: プロフィール画像編集UIを追加

# PR 4: テストと仕上げ
test: プロフィール画像機能のテストを追加

スクリーンショットとDraft PR

UI変更を含むPRでは、Before/Afterのスクリーンショットを 添付することでレビュアーの理解を大幅に助けます。

## スクリーンショット

| Before | After |
|--------|-------|
| ![before](url) | ![after](url) |

### 動作確認（アニメーションがある場合はGIF）
![demo](url)

Draft PRの活用

実装途中でもDraft PRとして公開することで、 早い段階でフィードバックをもらうことができます。

  • • 設計方針の確認を早めに行える
  • • 大きな手戻りを防止できる
  • • チームメンバーに作業の進捗を共有できる
  • • 「Ready for review」に変更するまでマージされない

Issueとの紐付けとコミットメッセージ

PRとIssueを紐付けることで、「なぜこの変更をしたか」のトレーサビリティが確保されます。 GitHubではキーワードを使って自動的にIssueをクローズできます。

## PR説明文でIssueを紐付ける

Closes #123       <!-- マージ時にIssue #123を自動クローズ -->
Fixes #456        <!-- バグ修正の場合 -->
Resolves #789     <!-- 同じく自動クローズ -->
Related to #101   <!-- 関連はあるがクローズしない -->
Part of #202      <!-- 大きなIssueの一部の場合 -->

良いコミットメッセージ

コミットメッセージも、将来の自分やチームメンバーのために丁寧に書きましょう。

# 良いコミットメッセージの構造
<type>: <subject>

<body>（任意）

<footer>（任意）

# 例:
feat: ユーザーアバター画像のアップロード機能を追加

- presigned URL を使用してS3に直接アップロード
- 画像サイズは最大5MBまでに制限
- WebP形式に自動変換してストレージ容量を節約

Closes #123

良い例

  • ✅ fix: カート合計金額が税込で計算されない問題を修正
  • ✅ refactor: UserRepositoryをinterfaceベースに変更
  • ✅ feat: 検索結果のページネーションを追加

悪い例

  • ❌ fix - 何を修正した？
  • ❌ update - 何を更新した？
  • ❌ aaa - 意味不明

まとめ

  • • PRタイトルにはプレフィックスを付けて変更内容を明確にする
  • • 説明文はWhat / Why / How / Testingの構成で書く
  • • PRは200行以下の小さな単位に分割する
  • • UI変更にはスクリーンショットを添付する
  • • Draft PRで早期にフィードバックを得る
  • • Issueとの紐付けでトレーサビリティを確保する
← 前のレッスン

コードレビューの基本

次のレッスン →

レビュー実践