раздел 09 · подстраница 4

Кейсы параллельной работы

Три развёрнутых сценария, в которых параллелизм реально экономит часы. Все три проверены на боевых проектах, не на демо.

Кейс 1. Три фичи параллельно в трёх worktree

Ситуация: лид сказал к пятнице сделать три независимые фичи - авторизация, биллинг и admin-панель. Делать последовательно - не успеть. Решение: три worktree, три Claude.

Подготовка

cd ~/app
git checkout main && git pull

git worktree add ../app-feat-auth feat-auth
git worktree add ../app-feat-billing feat-billing
git worktree add ../app-feat-admin feat-admin

В каждом worktree свой Claude

Открываем три терминала.

# Терминал 1
cd ~/app-feat-auth
claude
> Реализуй авторизацию через email/password. JWT в httpOnly cookie.
  Эндпоинты /api/auth/login, /api/auth/register, /api/auth/me.
  Тесты обязательны.

# Терминал 2
cd ~/app-feat-billing
claude
> Реализуй интеграцию со Stripe. Подписки monthly/yearly.
  Webhook /api/stripe/webhook. Сохраняй события в БД.

# Терминал 3
cd ~/app-feat-admin
claude
> Сделай admin-панель /admin: список пользователей, поиск,
  блокировка. Доступ только role=admin.

Что НЕ делать

  • Не запускать npm run dev во всех трёх. Поднимите его в одном worktree, остальные тестят через unit/integration.
  • Если кто-то тронул package.json - синхронизируйте остальных через rebase после мержа.

Сведение

В пятницу:

# В каждом worktree
git push -u origin <branch>
gh pr create --fill

# После апрува - мержим PR по очереди
gh pr merge feat-auth --squash
gh pr merge feat-billing --squash
gh pr merge feat-admin --squash

# Удаляем worktree
cd ~/app
git worktree remove ../app-feat-auth
git worktree remove ../app-feat-billing
git worktree remove ../app-feat-admin

Если фичи затрагивают одну и ту же область - первый мерж пройдёт чисто, второй потребует rebase, третий ещё один. Это нормально, на это закладывайте час буфера.

Кейс 2. Ресёрч 5 библиотек одновременно через Task

Ситуация: выбираем ORM для нового Python-проекта. Кандидаты - SQLAlchemy, Tortoise, Piccolo, Pony, peewee. Хочется быстро понять, кто живой и кто что умеет.

Один Claude, пять Task-вызовов

> Сравни 5 Python ORM: SQLAlchemy, Tortoise, Piccolo, Pony, peewee.

  Делегируй 5 субагентам researcher параллельно, каждому одна
  библиотека. Каждый собирает:
  - Дата последнего релиза
  - Звёзды на GitHub и активность за 12 месяцев
  - Async-поддержка (нативная или через костыли)
  - Тип-аннотации (mypy-friendly?)
  - Миграции (есть встроенные, нужен alembic, нет совсем)
  - Известные проблемы и громкие баги
  - Кто использует в проде (имена компаний)

  Источники - официальная дока + GitHub + 1-2 свежие статьи.
  Формат отчёта от каждого - markdown-таблица.

  После сбора - сведи в одну сравнительную таблицу, отсортируй
  по моему критерию: async + type-safety. Дай рекомендацию.

Что получим

Через 3-5 минут - таблица:

| Библиотека   | Async | Types | Migrations | Активность | Прод     |
| ------------ | ----- | ----- | ---------- | ---------- | -------- |
| SQLAlchemy   | да    | 4/5   | alembic    | очень      | reddit   |
| Tortoise     | да    | 3/5   | aerich     | средняя    | meta(?)  |
| ...

Без параллелизма - тот же отчёт занял бы 30+ минут одного Claude (контекст переполнился бы на третьей библиотеке).

Кейс 3. Миграция: backend, frontend, тесты - три агента

Ситуация: мигрируем с Express на Fastify. Меняется backend, меняется типизация на frontend (если есть генерация), переписываются интеграционные тесты.

Стратегия

Один тим-лид Claude в основном репо, три субагента в трёх worktree.

> Мигрируем backend с Express на Fastify.

  Делегируй 3 субагентам параллельно, каждый в своём worktree:

  Агент 1 - backend (worktree app-migrate-backend, ветка migrate-backend):
    - Перепиши src/server.ts на Fastify
    - Замени middleware: cors, helmet, body-parser - на Fastify-аналоги
    - Преобразуй роуты - app.get / app.post в fastify.get / fastify.post
    - Сохрани все эндпоинты с теми же URL и схемой ответа

  Агент 2 - frontend (worktree app-migrate-frontend, ветка migrate-frontend):
    - Проверь src/api/ на типизацию ответов от backend
    - Если есть генерация типов из OpenAPI - перегенерируй
    - Адаптируй error-handling под новый формат ошибок Fastify

  Агент 3 - tests (worktree app-migrate-tests, ветка migrate-tests):
    - Перепиши tests/integration/ на supertest с Fastify-app
    - Все эндпоинты должны быть покрыты
    - Запусти тесты, отрапортуй о падающих

  Каждый - свой worktree (используй isolation: "worktree").
  В конце сведи отчёты. Я сам решу, в каком порядке мержить.

Порядок мержа

1. backend → main (после ревью)
2. frontend → rebase на main → проверка → merge
3. tests → rebase на main → запуск тестов → merge

Тесты мержим последними - они валидируют, что первые два правильно работают вместе.

Если что-то пошло не так

# Backend замержен, но в frontend нашёлся баг
# Чиним в frontend-ветке
cd ~/app-migrate-frontend
# ... правки через Claude ...
git push

# Не откатываем main, чиним forward

Откат - только если backend поломал прод. Тогда:

git revert <backend-merge-commit>

Общие уроки

  • Параллелизм даёт x3-x5 ускорение на правильно делимых задачах
  • Координация - всегда на человеке: API не сделает её за вас
  • Worktree + branch + чёткие правила доступа к общим ресурсам = база
  • Сведение - отдельная фаза, её закладывайте в план

Полезные ссылки