Атомарные Задачи (Атомарная Декомпозиция Задач)

1. Обзор концепции и системная проблема

В классической разработке размытые задачи ("Сделать авторизацию", "Переписать модуль поиска") являются главным источником затягивания сроков и переработки. В эпоху разработки с участием AI-агентов цена плохой декомпозиции возросла многократно.

Когда инженер дает агенту высокоуровневую размытое указание, агент делает предположения о десятках неопределенных деталей. В результате генерируется монолитный дифф на 40 файлов, где смешаны верстка, схемы баз данных и бизнес-правила. Проверить такой дифф практически невозможно: инженер испытывает когнитивное перегрузку, нажимает "Accept", а через неделю сталкивается с неразрешимыми конфликтами.

Atomic Tasks (Атомарные задачи) — это инженерная дисциплина структурирования работы по принципу неделимости:

• Каждая подзадача фокусируется на одном изменении поведения или структуры.
• Она имеет четко очерченные входные параметры и ожидаемые выходные инварианты.
• Она может быть полностью реализована, протестирована и закоммичена отдельно от остальной системы.

Хаотичный монолит (Провал агента):
[Требование: "Сделай мне интернет-магазин"] ---> [LLM генерирует кашу на 30 файлов с заглушками]

Атомарная декомпозиция (Контролируемый успех):
[Требование: "Оформление заказа"]
   |
   +---> Задача 1: Создать Drizzle-схему таблицы Order + миграция (Проверка: db:push)
   |
   +---> Задача 2: Написать чистую функцию calculateTotal(items, discount) (Проверка: 5 unit-тестов)
   |
   +---> Задача 3: Реализовать POST /api/orders с валидацией Zod (Проверка: curl / API тест)
   |
   +---> Задача 4: Создать UI-форму оформления заказа (Проверка: компонент в браузере)

2. Архитектурная таксономия и ментальная модель

Градация уровней гранулярности задач (Task Granularity Spectrum):

1. Макро-уровень (System Feature / Epic):
   • Бизнес-цель (например, "Поддержка мультиязычности сайта"). Не подлежит прямому согласованию в чате агента как одна команда.
2. Атомарный модуль (Feature Slice / Component):
   • Вертикальный срез функционала (например, "Маршрутизация локалей через middleware").
3. Атомарное действие (Atomic Micro-Task):
   • Конкретный шаг по модификации одного слоя: "Создать словарь переводов для страницы 404 в формате JSON и добавить строгие типы ключевых слов".
   • Время выполнения: 2–5 минут.
   • Количество измененных строк: до 50–100 строк.

3. Технический пайплайн и внутренняя механика

Шаблон инженерной атомарной задачи (TASK_SPEC.md)

### Задача: Создание репозитория для хранения токенов сессии

**Контекст файлов:**
- Целевой файл: `src/lib/auth/session-store.ts`
- Тестовый файл: `src/lib/auth/__tests__/session-store.test.ts`
- Справочный контракт: `src/lib/auth/types.ts`

**Требования:**
1. Реализовать класс `RedisSessionStore`, который имплементирует интерфейс `SessionStore`.
2. Метод `saveSession(token, data, ttlSeconds)` должен устанавливать ключ с TTL с помощью команды Redis `SETEX`.
3. Метод `getSession(token)` должен возвращать десериализованный объект или `null`, если ключ отсутствует.

**Критерий завершения (Definition of Done):**
- Команда `npx vitest run src/lib/auth/__tests__/session-store.test.ts` возвращает 100% успешных тестов.
- Отсутствуют ошибки типизации: `npx tsc --noEmit` проходит с 0 ошибок.

Пайплайн выполнения атомарного шага:

1. Инженер формулирует TASK_SPEC с четким контекстом и тестом.
2. Агент читает ТОЛЬКО указанные 2-3 файла (чистое окно контекста, ноль галлюцинаций).
3. Агент пишет реализацию.
4. Запуск автотеста -> зеленый свет.
5. Инженер проверяет компактный дифф (20 строк) за 15 секунд.
6. Git commit: `git commit -m "feat(auth): implement redis session store"`

4. Практические инженерные сценарии в продакшене

01. Безопасная миграция базы данных на 10 миллионов строк

Вместо одной комплексной миграции команда разбивает задачу на 4 атомарные таски: 1) Добавить новую колонку как nullable; 2) Написать фоновый скрипт батч-синхронизации по 1000 строк; 3) Переключить запись в новую колонку; 4) Добавить ограничение NOT NULL и удалить старое поле. Каждый этап проверяется и деплоится отдельно, устраняя риск блокировки таблицы.

02. Выход из состояния творческого тупика во время дебага

Инженер не понимает, почему сложный алгоритм расчета маршрута возвращает неверный результат. Вместо бесплодного рассмотрения всего файла на 1000 строк, он разбивает алгоритм на 5 чистых подфункций и пишет к каждой отдельный тест. На 3-й подфункции оказывается ошибка округления дробей, и баг устраняется за 3 минуты.

03. Параллельный дирижабль субагентов (Parallel Subagents)

Благодаря атомарности архитектор может запустить 3 разные сессии модели одновременно: один агент пишет парсер XML, второй — генератор PDF отчетов, третий — схему базы данных. Поскольку их контракты атомарны и не пересекаются в общих файлах, отсутствуют любые конфликты слияния (Merge Conflicts).

5. Подводные камни, типовые ошибки и безопасность

1. Паралич фрагментации (Micro-Task Hell): Чрезмерная декомпозиция задачи на 50 мелких шагов по 30 секунд каждый создает бюрократическое трение: время на формулирование промпта и ожидание ответа начинает превышать время написания кода. Сохраняйте здоровый масштаб: 1 атомарная задача должна содержать содержательный шаг решения проблемы.
2. Потеря глобального инварианта (Local Optimum Trap): Каждая атомарная задача может быть выполнена идеально на своем уровне, но в комплексе модули могут не стыковаться, если изначально не был зафиксирован общий интерфейсный контракт (Contract-First Design).
3. Накопление незакоммиченного мусора: Если после выполнения каждой атомарной задачи не делать git commit, через 5 итераций рабочее дерево превращается в хаос из сотен непонятных изменений, и преимущества атомарности полностью теряются.