Driven-подходы: сравнение

Назначение материала: точка входа в серию «Driven-подходы»: сравнительная карта одиннадцати методологий, смежного AI-подхода и сатирических антипаттернов. Это обзор-навигатор: он сводит серию в одну систему координат и отвечает на вопросы «что читать», «чем подходы отличаются» и «как выбрать», не дублируя содержание отдельных статей.

Аудитория: руководители команд, руководители руководителей, CTO — те, кто выбирает инженерные и процессные практики для команд и организаций.

Как пользоваться: начните со сравнительной таблицы — она даёт снимок всей серии по шести осям. Если в разговоре сталкиваются два разных раскрытия одной аббревиатуры — загляните в дизамбигуацию коллизий. Если стоит задача «что внедрять у нас» — раздел выбора и группировка по семействам.

Общее #

Формула «X Driven Development» (или «X Driven Design») — одна из самых продуктивных в истории инженерии ПО. Она утверждает простое: у процесса разработки должна быть движущая сила — артефакт или практика, которая принимает решения за команду и отвечает на вопрос «почему мы делаем именно так». В TDD такой силой выступает тест, в DDD — предметная область, в Risk-DD — реестр рисков, в HDD — проверяемая гипотеза. Сам подход при этом обычно приносит три вещи: артефакт-драйвер (тест, модель, контракт, README), цикл работы с ним и критерий, по которому понятно, что решение принято «по правилам», а не по настроению.

Почему таких подходов так много? Потому что разработка — многоуровневая деятельность, и на каждом уровне болит своё. На уровне кода болит качество и изменчивость — отсюда тестовые и типовые драйверы. На уровне команды болит взаимопонимание с бизнесом — отсюда поведенческие и приёмочные. На уровне организации болит сложность домена, риски и неопределённость ценности — отсюда доменный, риск- и гипотезо-ориентированные подходы. Каждая новая аббревиатура — это, как правило, чья-то попытка назвать по имени конкретную повторяющуюся проблему и прилагаемый к ней артефакт. Формула оказалась настолько удачной, что индустрия присваивает суффикс «-Driven» всему, что способно «двигать» процесс, — вплоть до ироничных ярлыков вроде Panic Driven Development, где движущей силой становится паника.

Серия статей этой базы знаний разобрала двенадцать таких сил — одиннадцать «настоящих» методологий и оборотную сторону жанра, сатирические антипаттерны. Эта статья — тринадцатая, завершающая: она не пересказывает содержание выпусков, а сводит их в единую карту. Каждая строка таблицы ниже — дверь в отдельную статью с историей, механикой, преимуществами, рисками и границами применимости подхода.

Главный посыл карты: все «*DD» различаются движущей силой, а выбор зависит от того, какая проблема доминирует — качество кода, поведение, сложность домена, неопределённость ценности, риски или интеграция. Подходы не конкурируют за одно место: зрелая организация применяет несколько одновременно, каждое — на своём уровне. TDD страхует код, BDD — взаимопонимание с заказчиком, DDD — структуру системы, Risk-DD — фокус архитектурных усилий.

Читать серию можно в любом порядке: статьи самодостаточны и ссылаются друг на друга. Рекомендуемые маршруты: «инженерам» — TDD → Type-TDD → CDD; «аналитикам и продуктовым ролям» — BDD → ATDD → HDD; «архитекторам» — DDD → Risk-DD → MDD; «руководителям» — FDD → Readme-DD → антипаттерны.

Историческая линия серии занимает без малого три десятилетия и хорошо видна в порядке появления подходов: FDD Де Луки (1997) и TDD Бека (конец 1990-х, XP) — первая волна «процессных» и «инженерных» драйверов; DDD Эванса (2003) и BDD Норта (2003–2006) — вторая волна, перенёсшая движущую силу из практик кода в модели и язык; Readme-DD Престон-Вернера и Risk-DD Фэрбэнкса (оба — 2010) — третья волна «согласия и фокуса»; контрактное тестирование и CDD оформились в 2010-х вместе с микросервисной волной; AIDD — четвёртая волна, начавшаяся в 2023 году с массового внедрения LLM. Сатирические ярлыки сопровождали всю эту историю — фольклор пародировал каждую волну с одинаковым успехом.

При всём внешнем разнообразии у подходов серии общая анатомия, и её полезно держать в голове при чтении: артефакт-драйвер создаётся до основного труда (тест до кода, README до кода, гипотеза до фичи, контракт до интеграции), работа с ним организована коротким циклом с быстрой обратной связью, а решение считается принятым, когда артефакт «зелёный» — тест прошёл, код скомпилировался, контракт соблюдён, гипотеза подтверждена данными. Именно поэтому подходы совместимы: они не спорят об одном слоте «методология», а закрывают разные петли обратной связи.

Сравнительная таблица #

Центральный артефакт обзора — таблица, сводящая все подходы серии по шести осям. Колонка «Уровень» указывает, где подход работает в первую очередь: «код» — практики инженеров, «команда» — процессы взаимодействия, «организация» — структура, приоритеты, культура. Колонка «Статус» — оценка зрелости: «устоявшийся» означает канонические первоисточники и широкое промышленное применение, «нишевый» — известность в профессиональном сообществе при ограниченном распространении, «сатирический» — фольклорный ярлык без методологии (объект распознавания, а не внедрения).

Два примечания к таблице. Первое: AIDD (AI-Driven Development) не входит в основную серию — это смежная методология, вынесенная в раздел AI базы знаний; она включена в таблицу, потому что отвечает на тот же вопрос «что является движущей силой производства кода» и сталкивается с теми же антипаттернами (ближайший родственник по риску — Vibe Coding как генерация без дисциплины). Второе: строка антипаттернов агрегирует семь ярлыков одной статьи — при необходимости их сводно сравнивать между собой (симптомы, причины, антидоты) внутри статьи есть отдельная таблица.

Дизамбигуация коллизий #

Букв в алфавите меньше, чем причин писать «-Driven Development», поэтому аббревиатурные коллизии — не казус, а норма жанра. Четыре коллизии затрагивают подходы серии напрямую: в каждой из них за одним сокращением стоят принципиально разные вещи — от дисциплинированной методологии до фольклорного ярлыка больного режима.

Самая опасная для практики — коллизия TDD: оба значения легитимны, оба «пишут проверку до кода», но проверяют разное (поведение против структуры) и живут в разных культурах (агильная против функциональной). В разговоре «мы делаем TDD» заслуживает уточнения едва ли не всегда. Коллизии FDD и DDD асимметричны: первое значение — признанная методология, второе — ярлык больного режима; «у нас FDD» без уточнения может означать диаметрально противоположные состояния команды.

Отдельно от коллизий аббревиатур стоит семейное сходство TDD → ATDD → BDD: это не разные раскрытия одной аббревиатуры, а историческая линия развития («тест до кода» на уровнях юнита → приёмки → поведения). Их путают чаще, чем однофамильцев, поэтому в статьях каждой из трёх методологий есть отдельный разводящий раздел.

Практическое правило, снимающее все коллизии разом: при первом употреблении в любом документе или разговоре аббревиатуру следует раскрывать полностью — «TDD в смысле Test» или «RDD — про риски». Это стоит одной фразы и экономит часы рассинхронизированных обсуждений.

Как выбрать подход #

Выбор подхода — это не вопрос моды и не вопрос «какой лучше», а вопрос диагностики: что именно болит сейчас сильнее всего. Ниже — дерево выбора по доминирующей проблеме и две поправки: по уровню, на котором можно менять вещи, и по готовности команды.

Дерево выбора по оси «что драйвит»:

Какая проблема доминирует?
├─ Качество и изменяемость кода
│  ├─ нужно фиксировать поведение ............ TDD (Test)
│  └─ нужно фиксировать инварианты ........... TDD (Type)
├─ Взаимопонимание с бизнесом
│  ├─ поведение фичи целиком, общий язык ..... BDD
│  └─ критерии приёмки до старта ............. ATDD
├─ Сложность предметной области .............. DDD
├─ Неопределённость ценности ................. HDD
├─ Риски и цена отказа ....................... RDD (Risk)
├─ Интеграция между сервисами и командами .... CDD
├─ Согласие о «зачем» до «как» .............. RDD (Readme)
├─ Однотипные модели, кодогенерация .......... MDD
└─ Планирование и отчётность по фичам ........ FDD

Поправка по уровню. Если ваши рычаги ограничены уровнем кода — начинайте с практик кода: TDD, Type-TDD, CDD. Если можете менять процесс команды — добавляются BDD, ATDD, Readme-DD, элементы FDD. Если есть влияние на организацию в целом — именно там раскрываются DDD, HDD, Risk-DD и FDD; попытка решать организационные проблемы исключительно инженерными практиками (и наоборот) — типовая ошибка внедрения: TDD не вылечит хаос приоритетов, а FDD не починит дизайн кода.

Та же рекомендация в виде матрицы «уровень × движущая сила» — она отвечает на вопрос «какие подходы мне доступны с моей позиции»:

Поправка по готовности. Команда, в которой процессом управляет паника или крик, не удержит ни одну методологию серии: практика будет отброшена первым же «горящим» релизом. Поэтому честная последовательность внедрения — сначала снять больные режимы (наблюдаемость, приоритизация, психобезопасность — см. антипаттерны и их антидоты), затем вводить движущие силы. И ещё две эвристики: не внедряйте больше одной-двух новых практик за раз (каждая требует месяцев закрепления) и выбирайте подход под проблему, а не проблему под подход — движущая сила обязана отвечать на вопрос «почему», иначе она не движущая.

Для типового порядка внедрения, когда команда начинает «с нуля» и хочется сразу всё, работает такая последовательность (от фундамента к надстройке):

1. Readme-DD — дешёвая дисциплина «сначала опиши, потом делай»; не требует инструментов и сразу снижает долю работы «не туда».
2. TDD — страховка изменений; делает безопасными все последующие практики (рефакторинг под DDD, переезды контрактов).
3. ATDD/BDD — общий язык с заказчиком; фиксирует «что делаем» до того, как инженеры вложились в «как».
4. Risk-DD + DDD — фокус и глубина проектирования там, где цена ошибки высока.
5. CDD — контракты на стыках, когда команда выросла в несколько.
6. HDD и FDD — организационный слой: гипотезы ценности и фича как единица планирования.

Порядок не догма, а отражение зависимостей: спецификация дешевле теста, тест дешевле архитектуры, архитектура дешевле организационных изменений. Начинать с конца этой цепочки (внедрять DDD в команду без тестов и без приоритизации) — значит строить третий этаж поверх отсутствующего первого.

Группировка #

Тринадцать строк таблицы естественным образом собираются в четыре семейства — по типу движущей силы и уровню, на котором она работает.

Тестовые (спецификационные): TDD, ATDD, BDD. Движущая сила — исполняемая проверка, написанная до реализации. Все три выросли из одного корня «тест прежде кода», но живут на разных уровнях: TDD — инженерная микро-практика (юниты), ATDD — фиксация критериев приёмки, BDD — общий язык сценариев с заказчиком. В зрелой команде дополняют друг друга по вертикали «код → приёмка → поведение».

Архитектурные: DDD, MDD, Type-TDD, Contract-DD. Движущая сила — то, что определяет структуру и границы системы: модель предметной области у DDD, формальная модель у MDD, система типов у Type-TDD, контракты у CDD. Общий принцип семейства: структура системы не выдумывается, а выводится из явно зафиксированной модели или границы; «зелёный» сигнал (компиляция, пройденный контракт) доказывает, что граница держится.

Организационные: FDD, HDD, Risk-DD, Readme-DD. Движущая сила — артефакт, управляющий приоритетами, планом и фокусом: фича у FDD, гипотеза у HDD, реестр рисков у Risk-DD, README у Readme-DD. Эти подходы меняют прежде всего то, что и в каком порядке делает организация, — инженерные практики здесь следствие, а не причина.

Антипаттерны: сатирическое зеркало серии. Panic, Fear, Deadline, Scream, Coverage, Resume и Buzzword DD — не четвёртая методология, а диагностический словарь больного состояния: движущей силой становится давление. Полезны как зеркало: любую инициативу из трёх верхних семейств стоит проверять на то, не порождает ли она снизу свой антипаттерн (погоня за покрытием — Coverage DD, внедрение по моде — Buzzword DD).

Сводка семейств одной таблицей:

Семейства не конкурируют между собой: типичная зрелая организация применяет по одному-два подхода из каждого — тестовое семейство страхует код, архитектурное — структуру, организационное — приоритеты, а словарь антипаттернов держит под рукой как чек-лист самодиагностики.

Связанные подходы #

Серия «Driven-подходы» — двенадцать статей, каждая о своей движущей силе:

• TDD — Test Driven Development — тесты как исполняемая спецификация; цикл Red-Green-Refactor управляет дизайном кода.
• DDD — Domain Driven Design — домен и единый язык; модель кода как проекция модели бизнеса.
• BDD — Behaviour Driven Development — поведение в сценариях Given-When-Then; общий язык заказчика и разработчика.
• FDD — Feature Driven Development — клиенто-ориентированная фича как единица планирования и отчётности.
• MDD — Model Driven Development — формальная модель как источник истины; кодогенерация из модели.
• ATDD — Acceptance Test Driven Development — критерии приёмки, зафиксированные до реализации.
• HDD — Hypothesis Driven Development — гипотеза с критерием отказа; данные вместо мнений.
• TDD — Type Driven Development — система типов как пруфер; невалидные состояния невыразимы.
• RDD — Risk Driven Development — реестр рисков определяет глубину архитектурных усилий.
• CDD — Contract Driven Development — исполняемые контракты на стыках сервисов и команд.
• RDD — Readme Driven Development — README как спецификация до кода; «зачем» прежде «чем».
• Driven-подходы: антипаттерны — сатирические ярлыки больного состояния: Panic, Fear, Deadline, Scream, Coverage, Resume, Buzzword.

Смежные материалы базы знаний, в которых driven-подходы живут в более широком контексте:

• AIDD — AI Driven Development — AI как основной производитель кода; дисциплина спецификаций и валидации вокруг генерации.
• Domain-Driven Design (архитектурный разбор) — углублённый разбор стратегических и тактических паттернов DDD в разделе «Архитектура».
• ADR — Architecture Decision Records — фиксация архитектурных решений; естественная пара к Readme-DD и Risk-DD.
• Agile, Scrum и XP — процессные рамки, в которые встраиваются практики серии (XP — родина TDD).
• SDLC — жизненный цикл ПО: где именно применяются driven-подходы на его этапах.

Краткий вердикт для руководителя #

Серия «Driven-подходы» читается как один текст с простой грамматикой: суффикс «-Driven» называет движущую силу, а сила отвечает на вопрос «почему мы делаем именно так». Практический алгоритм из обзора умещается в три шага: назвать доминирующую проблему (качество кода, поведение, домен, неопределённость, риски, интеграция), выбрать подход из соответствующей строки таблицы и убедиться, что команда готова его удержать (больные режимы из статьи об антипаттернах сводят любую методологию на нет). Помните, что подходы дополняют, а не исключают друг друга: TDD и DDD, BDD и Risk-DD, FDD и HDD спокойно сосуществуют на разных уровнях одной организации — зрелость измеряется не количеством внедрённых аббревиатур, а тем, что каждое значимое решение в команде может вразумительно ответить на вопрос «какая сила его продиктовала». Если ответ — «срок», «крик» или «мода», подход выбран не вами: загляните в антипаттерны и подберите антидот.