Хабрахабр

TDDx2, BDD, DDD, FDD, MDD и PDD, или все, что вы хотите узнать о Driven Development

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

  • TDD — ну, это все знают, сначала пишем тесты, а потом остальной код.
  • BDD — что-то знакомое, вроде как, тоже тесты, но особенные.
  • TDD — снова? Так, стоп, тут речь уже не о тестах совсем. Но почему называется так же?
  • DDD — bound contexts, ubiquitous language, domain...
  • FDD — да сколько можно?
  • MDD — cерьезно, на основе диаграмм?
  • PDD — ...

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

Мы начнем знакомиться с ними от самых простых до довольно сложных, рассмотрим примеры использования и плюсы и минусы каждого из них.

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

Многим знаком такой подход к разработке и даже сам "Uncle Bob" активно его пропагандирует. Звучит просто и понятно.

Философия разработки на основе тестов заключается в том, что ваши тесты являются спецификацией того, как ваша программа должна вести себя. TDD считается одной из форм правильного метода построения приложения. Конечно, ограничение заключается в том, что правильность вашей программы определена только как полнота ваших тестов. Если вы рассматриваете свой набор тестов как обязательную часть процесса сборки, если ваши тесты не проходят, программа не собирается, потому что она неверна. Тем не менее, исследования показали, что разработка, основанная на тестировании, может привести к снижению ошибок на 40-80% в производстве.

Так происходит потому что вы будете работать вне «зоны комфорта», и это вполне нормально. Начав использовать TDD, вы можете почувствовать, что работаете медленнее, чем обычно.

После того, как вы ощутите, что написание тестов стало простой и естественной частью рабочего процесса, что вам больше не нужно думать об использовании TDD при работе над проектом, вы осознаете, что TDD влилось в вашу работу.

Также TDD часто упрощает программную реализацию: исключается избыточность реализации — если компонент проходит тест, то он считается готовым. Эта методология позволяет добиться создания пригодного для автоматического тестирования приложения и очень хорошего покрытия кода тестами, так как ТЗ переводится на язык автоматических тестов, то есть всё, что программа должна делать, проверяется.

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

Разработка через тестирование". Подробнее с принципами TDD вы можете ознакомиться, прочитав книгу Кента Бека "Экстремальное программирование.

TDD — Type Driven Development

Type Driven Development сокращенно пишется также, как и разработка через тестирование, поэтому обычно пишут полное название.

Типы также служат формой документации, которая гарантированно обновляется. При разработке на основе типов ваши типы данных и сигнатуры типов являются спецификацией программы.

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

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

К примеру, для JavaScript этот подход тяжелее применить, чем для TypeScript. Из минусов только возрастающая сложность у языков с динамической типизацией.

На хабре есть прекрасная статья про типизацию.

BDD — Behaviour Driven Development

В чем же отличие? Из-за некоторого методологического сходства TDD (Test Driven Development) и BDD (Behaviour Driven Development) часто путают даже профессионалы. TDD — это больше о программировании и тестировании на уровне технической реализации продукта, когда тесты создают сами разработчики. Концепции обоих подходов похожи, сначала идут тесты и только потом начинается разработка, но предназначение у них совершенно разное. BDD предполагает описание тестировщиком или аналитиком пользовательских сценариев на естественном языке — если можно так выразиться, на языке бизнеса.

Определенный человек(или люди) пишет описания вида "я как пользователь хочу когда нажали кнопку пуск тогда показывалось меню как на картинке" (там есть специально выделенные ключевые слова). BDD — behaviour-driven development — это разработка, основанная на описании поведения. А дальше классическая разработка с тестами. Программисты давно написали специальные тулы, которые подобные описания переводят в тесты (иногда совсем прозрачно для программиста).

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

Тексты сценариев записываются в определенной форме.

given — данное) какой-то контекст, Имея (прим.

when) происходит событие, Когда (прим.

then) проверить результат. Тогда (прим.

Может получиться что-то подобное:

Или другой пример на русском:

+Сценарий 1: На счету есть деньги+

Имея счет с деньгами

И валидную карточку

И банкомат с наличными

Когда клиент запрашивает наличные

Тогда убедиться, что со счета было списание

И убедиться, что наличные выданы

И убедиться, что карточка возвращена

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

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

В чем преимущество BDD?

  • Тесты читаемые для не программистов.
  • Их легко изменять. Они часто пишутся почти на чистом английском.
  • Их может писать product owner или другие заинтересованные лица.
  • Результаты выполнения тестов более "человечные".
  • Тесты не зависят от целевого языка программирования. Миграция на другой язык сильно упрощается.

Минусы:

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

Выходом из этой ситуации может оказаться выбор подходящего BDD фреймворка и правильно выстроенных процессов разработки.

Подробнее о BDD можно прочитать тут.

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

DDD — Domain Driven Development

DDD — это набор правил, которые позволяют принимать правильные проектные решения. Предметно-ориентированное проектирование не является какой-либо конкретной технологией или методологией. Данный подход позволяет значительно ускорить процесс проектирования программного обеспечения в незнакомой предметной области.

Domain-driven design, DDD) — это набор принципов и схем, направленных на создание оптимальных систем объектов. Предметно-ориентированное проектирование (реже проблемно-ориентированное, англ. В эти модели входит бизнес-логика, устанавливающая связь между реальными условиями области применения продукта и кодом. Процесс разработки сводится к созданию программных абстракций, которые называются моделями предметных областей.

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

Поэтому при объяснении я буду приводить поясняющие ссылки на самые достойные источники. В этой статье я стараюсь передать суть каждого подхода к разработке ПО, но про DDD можно написать не одну статью и охватить все нюансы в нескольких абзацах у меня не выйдет.

«Domain» переводится как «предметная область», и именно от предметной области отталкивается разработка и проектирование в рамках данного подхода. Основная цель Domain-Driven Design — это борьба со сложностью бизнес-процессов, их автоматизации и реализации в коде.

Ubiquitous language способствует прозрачному общению между участниками проекта. Ключевым понятием в DDD является «единый язык» (ubiquitous language). Как раз наоборот. Единый он не в том смысле, что он один на все случаи жизни. Все участники общаются на нём, всё обсуждение происходит в терминах единого языка, и все артефакты максимально должны излагаться в терминах единого языка, то есть, начиная от ТЗ, и, заканчивая кодом.

Данная модель представляет из себя словарь терминов из ubiquitous language. Следующим понятием является "доменная модель". Он ограничивает доменную модель таким образом, чтобы все понятия внутри него были однозначными, и все понимали, о чём идёт речь. И доменная модель, и ubiquitous language ограничены контекстом, который в Domain-Driven Design называется bounded context.

В этом контексте, по DDD, он становится спикером или оратором. Пример: возьмем сущность "человек" и поместим его в контекст "публичные выступления". А в контексте "семья" — мужем или братом.

Важно, чтобы ваш код читался как книга, был прост и понятен всем, кто владеет единым языком проекта. Теперь про код. Что я имею в виду?

Если в языке проекта вы используете выражения "продукт был добавлен", то следующий вариант не по DDD:

var product = new Product('apple')

product.save()

В коде написано, что мы создали продукт странным образом и сохранили его. Почему? Нужно его добавить. Как же все таки добавить продукт? Вот DDD код:

Product::add('apple');

Архитектура:

Domain-Driven Design не про это, Domain-Driven Design про язык и про общение. С точки зрения Domain-Driven Design абсолютно всё равно, какую архитектуру вы выберете.

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

Про DDD также есть статьи, которые я очень советую прочитать внимательно — тут и тут.

Что же нам это дает в итоге:

  • почти все участники команды могут читать код проекта;
  • постановка задач становится более явной;
  • баги бизнес логики становиться проще искать;
  • QA специалистам намного легче просматривать код и находить логические ошибки и баги.

Минусы:

  • требуется высокая квалификация разработчиков, особенно, на старте проекта;
  • не все клиенты готовы пойти на такие затраты, DDD нужно учиться всем участникам процесса разработки.

FDD — Features Driven Development

FDD представляет собой попытку объединить наиболее признанные в индустрии разработки программного обеспечения методики, принимающие за основу важную для заказчика функциональность (свойства) разрабатываемого программного обеспечения. FDD — Эта методология (кратко именуемая FDD) была разработана Джеффом Де Люка (Jeff De Luca) и признанным гуру в области объектно-ориентированных технологий Питером Коадом (Peter Coad). Основной целью данной методологии является разработка реального, работающего программного обеспечения систематически, в поставленные сроки.

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

  • разработка общей модели;
  • составление списка требуемых свойств системы;
  • планирование работы над каждым свойством;
  • проектирование каждого свойства;
  • конструирование каждого свойства.

При этом каждый процесс разбивается на задачи и имеет критерии верификации. Последние два шага необходимо делать во время каждой итерации.

Давайте поподробнее остановимся на каждом пункте.

Разработка общей модели.

Далее для каждой моделируемой области делается более детальный разбор. Разработка начинается c анализа широты имеющегося круга задач и контекста системы. После одна из предлагаемых моделей или их совокупность становится моделью для конкретной области. Предварительные описания составляются небольшими группами и выносятся на дальнейшее обсуждение и экспертную оценку. Модели каждой области задач объединяются в общую итоговую модель, которая может изменяться в течение работы.

Составление списка функций

Функции объединяются в так называемые "области" (англ. Информация, собранная при построении общей модели, используется для составления списка функций. subject areas) по функциональному признаку. domain), а они же в свою очередь делятся на подобласти (англ.

Функции представлены в виде «действие — результат — объект», например, «проверка пароля пользователя». Каждая подобласть соответствует определенному бизнес-процессу, а его шаги становятся списком функций (свойств). Список свойств в FDD – то же самое, что и product backlog в SCRUM. Разработка каждой функции должна занимать не более 2 недель, иначе задачу необходимо декомпозировать на более мелкими итерации.

План по свойствам (функциям)

Далее идет этап распределения функций среди ведущих программистов или по командам.

Проектирование функций

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

Реализация функции

Пишем код, убираем заглушки, тестируем.

После того, как свойство протестировано и ушло в продукт, берем следующее по приоритетам свойство, повторяем цикл дизайна/реализации.

Итого, в результате мы получаем:

  • документация по свойствам системы;
  • тщательное проектирование;
  • проще оценивать небольшие задачи;
  • тесты ориентированы на бизнес-задачи;
  • проработанный процесс создания продукта;
  • короткие итеративные циклы разработки позволяют быстрее наращивать функциональность и уменьшить количество ошибок.

Минусы:

  • FDD больше подходит для больших проектов. Небольшие команды разработки не смогут прочувствовать все преимущества данного подхода;
  • значительные затраты на внедрение и обучение.

MDD — Model Driven Development

Не вдаваясь в подробности, выделим только ключевые моменты. В последнее время много внимания в публикациях отводится теме архитектуры и разработке на основе моделей MDA (Model Driven Architecture) и MDD (Model Driven Development).

model-driven development) — это стиль разработки программного обеспечения, когда модели становятся основными артефактами разработки, из которых генерируется код и другие артефакты. Разработка, управляемая моделями, (англ.

Если говорить проще, то вся суть разработки сводится к построению необходимых диаграмм, из которых впоследствии мы генерируем рабочий код проекта.

Ведь основная бизнес-логика содержится в диаграммах и не сковывает нас рамками выбора языка программирования и инструментов разработки. Основная цель MDD — минимизация затрат, связанных с привязкой к конкретным системным платформам и программным инфраструктурам.

Он преобразует язык программирования высокого уровня в эквивалентную реализацию на машинном языке. Давайте немного отвлечемся и вспомним про компилятор. В MDD наши диаграммы — это еще один уровень абстракции, который не позволяет нам увязнуть в деталях разработки, а посмотреть на картину в целом. Моделью в этом случае является программа, написанная на языке высокого уровня, которая скрывает несущественные детали о ее реализации.

Причем автоматическая генерация кода варьируется от извлечения простого скелета приложения до получения конечной кодовой базы (что сравнимо с традиционной компиляцией). Диаграммы выступают в качестве своеобразных «чертежей», из которых различные автоматизированные и полуавтоматизированные процессы извлекают программы и соответствующие модели.

Причиной возросшего внимания к ним в настоящее время является то, что автоматизации поддается значительно больше процессов, чем раньше. Идея MDD не нова ‑ она использовались с переменным успехом и раньше. Одним из таких стандартов является пересмотренная версия Unified Modeling Language – UML 2. Это развитие отражается в появлении MDD-стандартов, что ведет к унификации соответствующих средств. 0.

По стандартам Object Management Group (OMG) создание приложения состоит из следующих шагов:

  • cначала разрабатывается модель предметной области проектируемого приложения, полностью независимая от имплементирующей технологии;
  • затем она трансформируется специальным инструментом в платформо-зависимую модель;
  • наконец, она переводится в исходный код на соответствующем языке программирования.

На основе одной концептуальной модели данных вы можете поддерживать несколько связанных с ней физических моделей для различных СУБД. Классический пример применения MDD, который используется уже давно, — моделирование баз данных.

Какие преимущества мы получаем:

  • ускоряется вывод минимального жизнеспособного продукта (Minimum Viable Product) на рынок;
  • сокращается время на: генерацию каркаса приложения, модели классов, базы данных;
  • постоянно обновляемая документация;
  • для участников проекта диаграммы намного нагляднее кода.

Минусы:

  • для внедрение MMD потребуется использовать специальные программные решения, такие как Rational Software Architect, Simulink или Sirius;
  • от программистов требуются внушительные знания проектирования диаграмм;
  • значительные финансовые затраты на интеграцию данной методологии.

PDD — Panic Driven Development

Давайте посмотрим более подробно, каковы принципы этой методологии. Если вы пробовали методологии agile разработки, то вы наверняка пробовали и PDD.

Новые задачи приоритетнее старых.

Новое всегда лучше и имеет более высокий приоритет. Всякий раз, когда в середине спринта появляется новая проблема, она имеет приоритет над любой запланированной работой. Нацеленность на обеспечение ценности для клиента требует, чтобы команда заботилась о новых фичах и откладывала ранее определенную работу. Странно, почему это не стало одним из принципов гибкой разработки?

Пишите столько кода, сколько нужно, чтобы решить проблему.

Ошибки могут быть исправлены только кодом. Разработчики пишут код для жизни. Но мы же не хотим терять драгоценное время? Обсуждение дизайна и UX может только замедлить разработку. Если исправление работает, проблема решена. Сначала напишите решение, потом проверьте своё предположение по исправлению.

Тесты должны писаться в конце.

Тесты полезны, но не являются приоритетными. После того, как исправление внедрено, тесты могут быть запланированы как задача, которая будет сделана в будущем. Ручного тестирования должно быть достаточно, чтобы доказать работоспособность реализованного решения. Вы можете позаботиться о них позже.

Доверьтесь своему инстинкту.

Искусство имеет внутреннюю инстинктивную составляющую. Программирование — это искусство. Напишите код. Доверься своей интуиции. Только смелым улыбается удача. Разверните его.

Процесс гибок.

Критические исправления требуют разных подходов. Любой процесс, созданный для разработки, тестирования и выпуска программного обеспечения, — это просто набор соглашений и правил, которые не высечены в камне. Ожидается, что вы согнёте процесс, чтобы выполнить задачу в срок, если этого требует бизнес.

Это процесс, управляемый менеджером.

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

Плюсы подхода:

  • высокая скорость разработки;
  • дешево;
  • заказчики счастливы, что наконец-то нашли толковых разработчиков.

Минусы:

  • все плюсы разобьются о технический долг и сложность проекта.

PDD своеобразный антипаттерн разработки, который, к сожалению, мы все время от времени практикуем.

Заключение

Мы познакомились только с малой его частью, рассмотрели достаточное количество практик разработки ПО, узнали об их преимуществах и недостатках. Мир agile разработки многогранен.

Надеюсь многие из вас узнали что-то новое о Driven Development практиках и теперь, встретившись лицом к лицу с аббревиатурами DDD, BDD, MDD вы не испытаете замешательства, а может даже захотите попробовать их на практике.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть