Skip to main content

将 50 个文件从 REST 迁移到 GraphQL

规划一次包含 50 个文件的从 REST 到 GraphQL 的迁移，将其拆分为互不冲突的工作包，并通过批量会话一次性运行所有工作包。
AuthorCognition
Category迁移
Features高级, Playbooks
1

使用 Ask Devin 确定迁移范围

你有 50 个文件从 src/lib/restClient.ts 导入，需要迁移到新的 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 为你自动生成运行手册——描述你的迁移模式，Devin 会生成一份完整的运行手册：在你的编排提示中引用这个运行手册，可以确保所有并行会话提交的 PR 看起来都像出自同一位开发者之手。
3

使用 Advanced Devin 启动多个并行会话

打开 Advanced Devin（Web 应用中的闪光图标），并向它提供编排指令。Advanced Devin 会分析你的代码库依赖关系图，创建独立的工作包，并为每个工作包启动一个批次会话——全部并行运行。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)
批准分组，并一次性启动这六个会话。先运行 Auth，在 Auth 合并后再运行 Admin。
4

查看并合并结果

每个会话都会打开自己对应的 PR。由于这些包彼此独立，你可以按任意顺序进行审查和合并——但要先合并 Auth，因为 Admin 依赖它；并且在每次合并后都运行完整 CI，以捕获任何意料之外的交互问题。在所有 8 个迁移 PR 都合并完成后，开启一个后续会话来清理死代码：