React Code Review

ゴール

React（Hooks/Class問わず）のコードを以下の観点からレビューする。

• •正しさ: UI状態とビジネスロジックが期待どおりに動作するか
• •UX: 操作性・レスポンス・エラーメッセージなどが適切か
• •パフォーマンス: 不要な再レンダリングや高コスト処理がないか
• •アクセシビリティ: a11yの基本を満たしているか
• •保守性: コンポーネント構造・責務分割・状態管理が妥当か

このスキルは、コンポーネント単体と画面単位／PR全体の両方レビューで使う。

レビュー手順（全体の流れ）

1. •変更の目的を把握する
   • •どの画面／機能のための変更か
   • •UI仕様（デザイン／振る舞い）が分かる範囲で確認する
2. •影響範囲を把握する
   • •ルーティング・状態管理（Redux/Zustand/Recoil 等）との関係
   • •APIコールや共通コンポーネントへの影響
3. •主要な観点でコードを確認する（以下のチェックリスト）
4. •気づいた点を優先度付きでコメントする
   • •[Critical]: バグ・セキュリティ・重大なUX問題
   • •[Major]: 保守性・パフォーマンス・設計上の課題
   • •[Minor]: 命名・スタイル・UIの細かな改善案
5. •最後にまとめコメントを書き、良い点も明示する

共通チェックリスト

正しさ・状態管理

• • 状態（state）が適切な粒度に分割されているか（親／子どちらが持つべきか）
• • props と state の役割が混ざっていないか
• • 非同期処理（fetch, axiosなど）のエラー時挙動が定義されているか
• • ローディング・エラー・空データなどの状態が分岐されているか
• • フォームのバリデーションが適切か（必須・フォーマット・範囲など）
• • URLパラメータやクエリに依存するロジックが正しく扱われているか

Hooksの使い方（関数コンポーネントの場合）

• • useState / useReducer の使い分けが妥当か（複雑な状態はreducerを検討）
• • useEffect の依存配列が正しく指定されているか（漏れ／過剰がないか）
• • useEffect 内で同期的に状態を何度も更新していないか
• • クリーンアップ関数でイベントリスナやタイマーが適切に解放されているか
• • useMemo / useCallback を本当に必要な箇所にのみ使っているか
• • カスタムフックに分離できそうなロジックがコンポーネントに肥大していないか

JSX / コンポーネント構造

• • コンポーネントが1つの責務に収まっているか（巨大コンポーネントになっていないか）
• • map レンダリング時に key が安定した一意の値になっているか（index乱用していないか）
• • プレゼンテーションとロジックが適度に分離されているか
• • 条件分岐が読みやすく書かれているか（早期return・小コンポーネント化など）
• • スタイルの適用方法（CSS Modules, styled-components, Tailwind 等）がプロジェクト方針に沿っているか

パフォーマンス

• • 親の再レンダリングにより子コンポーネントが不要に再レンダリングされていないか
• • 大きなリストやテーブルに対してバーチャルスクロールなどが必要か検討されているか
• • 毎レンダリングごとに新しい関数やオブジェクトを大量に生成していないか
• • 非同期処理で不要になった結果を適切に無視しているか（レースコンディション対策）

アクセシビリティ・UX

• • フォーム要素にラベル（<label>+htmlFor や aria-label）が紐づいているか
• • ボタンやリンクが適切なHTMLタグで実装されているか（div+onClick乱用していないか）
• • キーボード操作（Tab移動／Enter／Space）で利用可能か
• • フォーカスインジケータが見えなくなっていないか（outline除去の有無）
• • 色だけに依存した情報伝達になっていないか
• • エラーメッセージやバリデーション結果がユーザーに分かりやすく表示されているか

型・保守性（TypeScriptを使用している場合）

• • any の乱用がないか
• • コンポーネントのprops型が明示されているか
• • APIレスポンスなどドメインデータの型が定義され再利用されているか
• • null / undefined の扱いが型レベルで表現されているか

APIコール／データフェッチの観点

• • 同じデータを複数箇所でフェッチしていないか（キャッシュや共通フックの利用を検討）
• • エラー時のリトライや、ユーザーへのフィードバックが実装されているか
• • コンポーネントアンマウント時の処理キャンセル（AbortController等）が必要か確認されているか

コメントの書き方ガイド

レビューコメントは、ユーザー体験とチーム方針を意識した具体的な提案を含める。

• •Bad: 「このuseEffectはよくないです」
• •Good: 「このuseEffectは依存配列にuserIdが含まれていないため、ユーザー切り替え時にデータが再取得されません。[userId] を依存配列に追加することを検討してください」

推奨フォーマット:

• •[Critical] 内容: 明らかなバグ・セキュリティ・重大なUX劣化
• •[Major] 内容: 設計・保守性・パフォーマンスに関する重要な改善
• •[Minor] 内容: 命名・スタイル・UI微調整など

出力フォーマット（テンプレート）

Reactコードをレビューするときは、次の形式で出力する。

### 概要
- 変更の目的と全体的な印象を1〜3行でまとめる。

### 良い点
- 良い点1
- 良い点2

### 指摘事項
- [Critical] 箇所と理由、修正案
- [Major] 箇所と理由、修正案
- [Minor] 箇所と理由、修正案

### UX / アクセシビリティの観点
- 改善できそうな点や懸念点があれば記載（なければ「特になし」と明記）

### 補足・提案（任意）
- コンポーネント分割や状態管理の改善案など、長期的な提案があれば記載

このテンプレートに沿って、コードの観点だけでなくユーザー体験も意識したレビューを行うこと。