Skip to main content

50ファイルをRESTからGraphQLへ移行する

50ファイル分のRESTからGraphQLへの移行範囲を決め、競合のない作業パッケージに分割し、バッチセッションで一括実行します。
AuthorCognition
Category移行
Features高度, プレイブック
1

Ask Devin で移行範囲を定義する

src/lib/restClient.ts からインポートしているファイルが 50 個あり、それらを新しい graphqlClient に移行する必要があります。作業を分担して進める前に、これらのファイル同士がどうつながっているかを把握する必要があります。Ask Devin を使ってマイグレーションの対象範囲をマッピングします。どのファイルがレガシークライアントをインポートしているか、それらがドメインごとにどうグルーピングされているか、リスクの高い結合がどこにあるかを洗い出します。Devin は内部で DeepWiki とセマンティック検索を使っているため、実際のコードに基づいてこうした質問に答えることができます。
Ask Devin を利用するには、リポジトリがインデックス済みである必要があります。Settings > Repositories に移動してインデックス状況を確認するか、新しいリポジトリをインデックスしてください。
Ask Devin を開き、次のように依頼します:Ask Devin は次のような内訳を返します:
50個のファイルが8つのドメインにわたってrestClientをインポートしています:

  User Management  (7ファイル) — 独立、テストカバレッジ完全
  Billing          (9ファイル) — 独立、6/9テスト済み
  Analytics        (5ファイル) — 独立、3/5テスト済み
  Auth             (6ファイル) — 共有ミドルウェア、テストカバレッジ完全
  Notifications    (8ファイル) — 独立、5/8テスト済み
  Admin            (5ファイル) — Authミドルウェアに依存
  Search           (4ファイル) — 独立、2/4テスト済み
  Onboarding       (6ファイル) — 独立、4/6テスト済み

結合に関する注意: AdminはAuthからrequireAuthをインポートしています。
まずAuthを移行し、次にAdminを移行してください。他のドメインはすべて独立しています。
これは、並列化する意味があるかどうかを判断するのに役立ちます。ほとんどのファイルがドメイン間で密結合されている場合は、順次マイグレーションの方が安全です。ここでは、8個のドメインのうち6個が完全に独立しているため、それらを並列に実行できます。
2

移行プレイブックを作成する

すべての並列セッションで同じ移行パターンに従うことで、最終的なPRが一貫したものになり、レビューしやすくなります。各ファイルをどのように移行するかを正確に定義したプレイブックを作成してください。Settings > Playbooks > Create Playbook に移動し、次の手順を定義します:またはAdvanced Devinを使ってプレイブックを自動生成することもできます。移行パターンを説明すると、その内容に基づいて完全なプレイブックを生成します:このプレイブックをオーケストレーション用プロンプト内で参照することで、すべての並列セッションが、同じ開発者が作成したかのように見えるPRを生成できるようになります。
3

Advanced Devin で並列セッションを開始する

Advanced Devin（ウェブアプリのきらめきアイコン）を開き、オーケストレーション用のプロンプトを入力します。Advanced Devin はコードベースの依存関係グラフを解析し、独立した作業パッケージを作成してパッケージごとに 1 つのバッチセッションを起動し、すべてを同時に実行します。Advanced Devin は、セッションを開始する前に、あなたが承認できるようグルーピング案を提示します。
提案された作業パッケージ（8グループ、合計50ファイル）:

グループ1 — ユーザー管理（7ファイル、複雑度: M）
  src/services/UserService.ts, src/pages/Profile.tsx,
  src/pages/Settings.tsx, src/hooks/useCurrentUser.ts,
  src/pages/UserDirectory.tsx, src/services/AvatarService.ts,
  src/components/UserCard.tsx

グループ2 — 請求（9ファイル、複雑度: L）
  src/services/BillingService.ts, src/services/InvoiceService.ts,
  src/services/SubscriptionService.ts, src/pages/Checkout.tsx,
  src/pages/PlanSelector.tsx, src/pages/InvoiceHistory.tsx,
  src/components/PaymentForm.tsx, src/hooks/useSubscription.ts,
  src/components/PricingTable.tsx

グループ3 — 分析（5ファイル、複雑度: S）
  src/services/AnalyticsService.ts, src/pages/Dashboard.tsx,
  src/components/MetricsCard.tsx, src/hooks/useMetrics.ts,
  src/components/ChartPanel.tsx

グループ4 — 認証（6ファイル、複雑度: L）⚠ 最初に移行
  src/services/AuthService.ts, src/middleware/requireAuth.ts,
  src/middleware/refreshToken.ts, src/pages/Login.tsx,
  src/pages/Signup.tsx, src/services/SessionService.ts

グループ5 — 通知（8ファイル、複雑度: M）
  src/services/NotificationService.ts, src/services/EmailService.ts,
  src/services/PushService.ts, src/pages/NotificationPreferences.tsx,
  src/components/NotificationBell.tsx, src/hooks/useNotifications.ts,
  src/components/NotificationToast.tsx, src/services/WebhookService.ts

グループ6 — 管理（5ファイル、複雑度: M）⚠ 認証に依存
  src/pages/AdminDashboard.tsx, src/pages/AdminUsers.tsx,
  src/services/AdminService.ts, src/components/AdminSidebar.tsx,
  src/middleware/requireAdmin.ts

グループ7 — 検索（4ファイル、複雑度: S）
  src/services/SearchService.ts, src/pages/SearchResults.tsx,
  src/components/SearchBar.tsx, src/hooks/useSearch.ts

グループ8 — オンボーディング（6ファイル、複雑度: M）
  src/services/OnboardingService.ts, src/pages/Welcome.tsx,
  src/pages/SetupWizard.tsx, src/components/ProgressTracker.tsx,
  src/hooks/useOnboardingState.ts, src/services/ChecklistService.ts

依存関係の注記: グループ6（管理）はグループ4（認証）からミドルウェアをインポートします。
認証を最初に起動し、認証のPRがマージされた後に管理を起動します。
残り6グループは直ちに並列で起動します。

6つの並列セッションを今すぐ開始 + 2つを順次実行しますか？（y/n）
グルーピングと 6 セッションの一括起動を承認してください。最初に Auth が実行され、Auth がマージされ次第 Admin が続きます。
4

結果をレビューしてマージする

各セッションはそれぞれ専用のPRを開きます。パッケージ同士は独立しているので、任意の順序でレビューとマージができますが、Admin が Auth に依存しているため、Auth を先にマージしてください。また、予期しない影響を検知するために、各マージ後には必ずフル CI を実行してください。8つすべての移行PRがマージされたら、後続のセッションでデッドコードをクリーンアップしてください: