review-duplication

重複のレビュー

概要

このスキルでは、コードレビュー中にコードベースを調査し、重複したロジック、独自に再実装されたユーティリティ、既存のパターンを再利用する機会の見落としを特定するための、体系的なワークフローを提供します。このワークフローを実行することで、新しいコードを既存のプロジェクトアーキテクチャにシームレスに統合できます。

ワークフロー：重複の調査

コードをレビューする際は、レビューを確定する前に次の手順を実行してください。

1. コアロジックを抽出する

新しいコードを分析し、導入される中核的なアルゴリズム、ユーティリティ関数、汎用データ構造、UI コンポーネントを特定します。具体的なビジネスロジックだけでなく、その基盤となる仕組みにも注目してください。

2. 既存箇所を推測し、依存関係を追跡する

この種のコードがプロジェクトにすでに存在するなら、どこに配置されているかを考えます。場所を明確にするため、リポジトリのルートからの絶対パスを示してください。

• ユーティリティ： packages/core/src/utils/、packages/cli/src/utils/
• UI コンポーネント： packages/cli/src/ui/components/、packages/cli/src/ui/
• サービス： packages/core/src/services/、packages/cli/src/services/
• 設定： packages/core/src/config/、packages/cli/src/config/
• コアロジック： React の UI に固有ではない機能の場合は、packages/core/ を挙げてください。

サードパーティ依存関係を追跡する： PR でユーティリティライブラリ（例：lodash.merge、date-fns）の新しいインポートが追加されている場合、プロジェクトでそのライブラリが現在どのように、どこで使われているかを追跡します。既存のラッパーや共通ユーティリティがある可能性があります。

パッケージファイルを確認する： 複雑なアルゴリズムの独自実装を指摘する前に、package.json を確認し、その機能を提供する標準ライブラリ（lodash や uuid など）がすでにインストールされていないか調べてください。

3. コードベースを調査する（サブエージェントへの委任）

コードベースの調査に必要な作業は、専門のサブエージェントに委任してください。サブエージェントは、セッション履歴を肥大化させずに、詳細な検索や意味的なマッピングを行えるよう最適化されています。

包括的なレビューを行うため、サブエージェントには、ステップ 1 で見つけた「手がかり」を提示し、具体性の高い目標を必ず設定してください。

• コードベース調査エージェント： 主な調査担当として codebase_investigator を使用します。委任する際は、次の検索観点を明示したうえで、コードベースに関する具体的な調査質問を含む目標を設定してください。
  • 構造的な類似性： 既存コードで同じ基盤 API が使われているかを尋ねます（例：「同様の目的で Intl.DateTimeFormat や setTimeout を使用している既存コードはありますか？」）。
  • 命名規則： 類似した命名パターンを持つ既存シンボルがあるかを尋ねます（例：「*Format* や *Debounce* のような命名パターンを持つ既存シンボルはありますか？」）。
  • コメントとドキュメント： PR のコメントや JSDoc に含まれるキーワードが、同様の動作を説明する別の箇所に存在するかを尋ねます。
  • アーキテクチャ上の適合性： この種のロジックが現在どこに集約されているかを尋ねます（例：「日付のフォーマット処理はどこに集約されていますか？」）。
  • リファクタリングの指針： 重要な点として、見つかった既存ロジックを使って新しいコードをどのようにリファクタリングできるか、サブエージェントに説明を求めます。
• 汎用エージェント： 詳細で複数ターンにわたる比較には generalist を使用します。たとえば、「PR の MyNewComponent の実装をレビューし、packages/ui/src 内のすべてのコンポーネントと意味的に比較してください。拡張または代わりに使用できる既存コンポーネントはありますか？」のように依頼します。
• 単純な検索は高速に行う： 極めて単純で明確な確認（例：「package.json に lodash は含まれていますか？」）は、時間を節約するため直接検索してください。自由形式の「調査」については、原則として委任します。

4. ベストプラクティスに照らして評価する

新しいコードが、プロジェクトで確立されている規約に準拠しているか確認します。

• エラー処理： プロジェクト標準のエラークラスやロギングの仕組みを使用していますか？
• 状態管理： 確立されているストアやコンテキストを迂回していませんか？
• スタイリング： テーマ変数を使わず、色や余白をハードコードしていませんか？ PR で新しいパターンが導入されている場合は、文書化されている標準と比較し、代わりに既存のプロジェクトパターンを使うべきだったかどうかを明確に伝えます。

5. 建設的なフィードバックを作成する

PR で既存の機能が重複している、またはベストプラクティスが無視されていることがわかった場合：

• 明確なレビューコメントを記載します。
• 参照元を特定する： 再利用すべきファイルの絶対パスまたはプロジェクト相対パスと、該当するシンボル（関数、コンポーネント、クラス）を明記します。
• 実装方法を提示する： 既存のコードを統合して要件を満たす方法を示す、簡潔なコードスニペットまたは明確な説明を記載します。
• 利点を説明する： 既存のコードを再利用する利点（保守性、一貫性、組み込みのエッジケース処理など）を簡潔に説明します。

コメント例：

「この PR では新しい formatDate ユーティリティを導入しているようです。src/utils/dateHelpers.ts に、堅牢でテスト済みの formatDate 関数がすでにあります。

次のようにインポートして、実装を置き換えられます。

import { formatDate } from '../utils/dateHelpers';

// ここで使用します：
const displayDate = formatDate(userDate, 'MMM Do, YYYY');

既存の関数を再利用すると、アプリケーション全体で日付の書式が統一され、タイムゾーン変換も正しく処理できます。」