コードレビューはチームのコード品質を向上させる最も効果的な手段の1つです。しかし多くのチームは実施しなかったり、形式的になりがちです。この記事では私たちのチームの実践経験をご紹介します。

コードレビューが投資に値する理由

• バグの発見：テストで発見するよりコストが10分の1
• 知識の共有：新人がチームのベストプラクティスを素早く学べる
• スタイルの統一：「個人スタイル」のコードを減らせる
• 設計の把握：コードがマージされる前にアーキテクチャの問題を発見
• 知識の分散：1人しかわからないコードを防ぐ

PRの規約

良いPRはレビュアーの作業を楽にし、悪いPRはどこから見ればよいかわからなくなります。

PRのサイズ：1つのPRあたり最大400行の変更（自動生成ファイルを除く）。大きな機能は複数のPRに分割します。

PR説明テンプレート：

## 実施内容

ユーザーがプロフィール設定でアバターをアップロードできるようになりました。

## 変更内容

- クロップ機能付きの`AvatarUpload`コンポーネントを追加
- `userStore`に`updateAvatar`アクションを追加
- アップロード制限：5MB、jpg/png/gif対応

## テスト確認

- [x] 通常のアップロードフロー
- [x] ファイルサイズ超過の警告
- [x] 非対応ファイル形式の警告
- [x] アップロード失敗時のリトライ

## スクリーンショット

[アバターアップロードのスクリーンショット]

レビュアーが注目すべき点

必須確認

正確性

// ❌ ロジックエラー：&&ではなく||を使うべき
if (!isAdmin && !hasPermission) {
  // 意図：管理者OR権限がある場合は通過させる
}

// ✅ 修正後
if (!isAdmin && !hasPermission) {  // 両方ない場合のみ拒否

セキュリティ

// ❌ ユーザー入力をHTMLに直接挿入
element.innerHTML = userInput;

// ❌ 機密情報をログに出力
console.log("Token:", userToken);

エッジケース

// ❌ 空配列の処理なし
const firstItem = list[0].name; // listが空の時クラッシュ

// ✅
const firstItem = list[0]?.name || "不明";

重点確認

保守性：関数が長すぎないか？ロジックが複雑すぎないか？変数名はわかりやすいか？

// ❌ 理解しにくい
function p(d, t) {
  return d.filter((i) => i.s === t).map((i) => i.v);
}

// ✅ 明瞭
function filterValuesByStatus(data, targetStatus) {
  return data
    .filter((item) => item.status === targetStatus)
    .map((item) => item.value);
}

重複コード：同じロジックが複数回出現していないか？抽出すべきか？

パフォーマンス問題：

// ❌ レンダリングループ内で重い処理
// Vueテンプレート内：
<li v-for="item in list" :class="{ active: expensiveCompute(item) }">

// ✅ 事前計算
computed: {
  processedList() {
    return this.list.map(item => ({
      ...item,
      isActive: this.expensiveCompute(item)
    }))
  }
}

不要な指摘

• コードスタイル（ESLintが処理）
• 細かな命名の好み（可読性に影響しない限り）
• 実装方法（正確で保守可能なら問題なし）

良いフィードバックの出し方

良くないレビューコメント：

このコードはひどすぎる、書き直して。
この関数は長すぎる。

良いレビューコメント：

ここのforループはArray.reduceで簡略化できます。
また現在の実装は時間計算量がO(n²)なので、
データ量が多い場合はパフォーマンス問題になります。
参考：[リンク]

calculateTotalPrice(items)のような独立した関数に
抽出することを検討してください。他の場所でも再利用でき、
テストも書きやすくなります。

任意提案：ここに境界チェックを追加して、listが空の場合は
直接[]を返すと、後続の処理で異常が発生しにくくなります。（必須ではありません）

レビューのペース

• 一度に500行以上レビューしない
• 複雑なPRには専用の時間を確保し、すきま時間にレビューしない
• コメント後は作者の修正を待つ。新たな問題を後から見つけない（最初のレビューで全部確認する）
• PRは課題ではなくコラボレーションツール。権威的なレビューは避ける

PRでアーキテクチャを争わない

アーキテクチャレベルの問題を見つけた場合、まず話し合い、PRを拒否しない：

1. 要議論とマークして、オフラインやissueで議論
2. 小規模プロジェクトで影響が少ない場合は先にマージして後でリファクタリング
3. 本当に変更が必要な場合は「書き直して」ではなく具体的な提案を

まとめ

• PRは小さく集中的に。明確な説明を添える
• レビューは正確性・セキュリティ・保守性に集中
• フィードバックは具体的で建設的に。「必須修正」と「提案」を区別する
• コードレビューは協力であり、審判ではない