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

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



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

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


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


    TDD — Test Driven Development


    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 Design



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


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

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


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


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


    Ключевым понятием в DDD является «единый язык» (ubiquitous language). 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) была разработана Джеффом Де Люка (Jeff De Luca) и признанным гуру в области объектно-ориентированных технологий Питером Коадом (Peter Coad). FDD представляет собой попытку объединить наиболее признанные в индустрии разработки программного обеспечения методики, принимающие за основу важную для заказчика функциональность (свойства) разрабатываемого программного обеспечения. Основной целью данной методологии является разработка реального, работающего программного обеспечения систематически, в поставленные сроки.


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

    Минусы:


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

    MDD — Model Driven Development



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


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

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


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


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


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


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

    Поделиться публикацией

    Комментарии 59

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

      В голову приходит пара выражений из школьно-институтского описания вводной ситуации в задаче/теореме — «Дано» и «Положим».
        +1

        FDD это вообще не разработка, это привод гибких дисков!
        (/сарказм)

          0
          FDD также Frequency-division Duplexing — дуплексирование с частотным разделением.
            0

            Угу, а MDD — это major depressive disorder.

              +1

              Расстроенный депрессивный майор?

            0
            Не хватает CDD как быстрого средства прототипирования8)
              0

              При желании можно расшифровать как Crutch Driven Development.-)

                0
                Не знаю, оно почему-то описывается как шуточный метод. Однако я так совсем не считаю. Если я хочу собрать полку из досок, я сначала делаю замеры и разметку карандашом. В программировании все сразу начинают пилить. Делать наборосок с помощью комментариев помогает мне вообще понять, что где будет находиться. Вырисовывается структура. Чаще такой подход я применяю при прототипировании алгоритмов. Можно в словах описать сам рецепт, а потом написать по нему код. Может это только новички так делают. Опытные программисты наверное планируют в голове, а не «на бумаге».
                Но тогда таким программистам и тесты не нужны, и все прочие методологии, они сразу пишут готовое приложение, а архитектура у них рождается «на кончике пера».
                  0
                  CDD это шутка, в которой есть доля правды:) Согласен про алгоритмы — бывает удобно сначала накидать комментарии, чтобы оценить будет ли все правильно работать в итоге. Еще один жизненный вариант, как раз приведенный в wiki — записать то, что планируется реализовать в заглушке для интерфейса. В целом, это можно рассматривать как часть вполне серьезного подхода — «proof of concept».
                    0
                    Да, есть подобный метод для создания минимально жизнеспособного продукта (minimum viable product, MVP). Получается своего рода прототип приложения с минимальной функциональностью. В таком продукте заказчики могут изменить все что угодно, поэтому код должен писаться быстро и модульно.
                  0

                  На картинке тем временем некий TTD вместо TDD

                    –1

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

                      0

                      Дмитрий, существуют ли общепринятые мнемоники для токенов в AST?

                        0

                        Не понял о чём вы.

                        0

                        Не могу согласиться с вами, поскольку BDD вовсе не язык программирования. Это методология. Поэтому ваш аргумент не уместен.

                          0

                          Это методология создания и поддержки языка программирования.

                            0

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

                        +2
                        BDD неудобен хотя бы тем, что требует привлечения специалистов тестирования уже на этапе проработки требований, а это удлиняет цикл разработки.
                        Привлечение тестировщиков на стадии проработки требований удлиняет цикл разработки только в одном случае — когда этапа тестирования нет. В любом другом варианте чем раньше вы привлечете специалистов по тестированию, тем проще и быстрее будет проходить разработка и последующее тестирование проекта.
                        BDD дорог и неудобен исключительно тем, что его нужно поддерживать — переводить тесты с естественного языка в код. Это очень не слабый оверхед и выгодно это только в случае когда сценарии пишет заметное количество менеджеров. BDD — это инструмент кооперации который позволяет добавить в цикл разработки менеджеров и аналитиков если им больше нечем заняться. Обычно же после первого восхищения у всех этих людей находится уйма дел которые нужно делать еще вчера и никаких тестов вы от них не дождетесь.
                          0

                          Вы правда думаете, что значительно количество менеджером смогут написать непротиворечивые сценарии? С этим и программисты-то не всегда справляются даже водиночку.

                            0
                            А при чем тут что я думаю про их возможности? Я описывал ограничения применения инструмента. Если у вас нет большого количества людей которые пишут тесты, но не умеют программировать, то вам BDD не нужен. Он будет потреблять больше ресурсов чем приносить.
                            Нет, на самом деле есть еще один кейс когда BDD может пригодиться: он может упрощать задачу отдела продаж добавляя еще одно умное слово к заклинанию которым продажники будут зачаровывать клиентов. Но в таком варианте BDD совершенно необязательно поддерживать и развивать, его достаточно просто иметь где-то в уголке и сдувать с него пыль раз в месяц.
                              0
                              Нет, на самом деле есть еще один кейс когда BDD может пригодиться ...
                              и ещё один: использование BDD в сочетании с User Story (для соответствующих, в основном ключевых, требований) эффективно при подготовке методики приёмо-сдатки и, особенно, для согласования её с Заказчиком.
                                0
                                большого количества людей которые пишут тесты, но не умеют программировать

                                написание тестов — это и есть программирование.

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

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

                                0

                                Вот в более-менее основной затык. Слишком менее, чтобы бизнес его писал, и слишком более, чтобы его писали программисты.

                                  0

                                  Да, ну из моего опыта — если нет чувства "балансирования" — скорее всего — ты и не двигаешься, а стоишь, приперевшись к стенке ;)

                                  0
                                  Мне всегда казалось, что BDD удобен как-раз тем, что заставляет сначала более-менее человеческим языком описать сценарий ...
                                  1. Замечу, что BDD удобен как раз тем и там, где реализация нагружена нетривиальным или специфическим прикладом, и, когда представителям бизнеса Заказчика, управленцам из разработки, программистами и тестировщикам надо понимать друг друга.
                                  2. Казалось-то Вам правильно, но, согласитесь — писать BDD надо представителям бизнеса и/или Аналитикам, а, по опыту коллег (см. комменты выше, и из моей практики) — они или не смогут нормально это сделать или тупо не захотят, отмажутся типа это им некогда, нет ресурсов, например, как Вы процитировали слова Автора в своём комменте: «BDD дорог и неудобен…». Добавлю, что им придётся не только писать BDD, это хозяйство им надо будет сопровождать/версионировать, поддерживая в актуальном состоянии.
                                  Итого: кадры, способные делать это быстро и грамотно, — большая редкость, большинство из того, что имеем, или некомпетентно или им и без BDD хорошо «живётся», когда разработка страдает.
                                    0

                                    По поводу первого — соглашусь полностью. Ключевое, кстати — отсутствие слова "должен" и наличие слова "удобен".


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


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


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

                                0
                                Полезно.
                                  +2
                                  Так я оказывается по PDD работаю последние 3 года… Вот это открытие!
                                    0

                                    Я год работал в компании, которая за 5 лет своего существования по технологии PDD выпустила несколько неплохих, но к сожалению, локальных продуктов. Реальность правда взяла своё и после ухода самого крупного заказчика, компания не смогла остаться на плаву и пару лет назад закрылась. Отчасти и потому, что PDD привело в какой-то момент к срыву сроков на полгода.

                                      0
                                      Очень редко укладываемся в сроки ) Это прям масштабное событие, которое можно отмечать =D
                                    +1
                                    Мне нравится другая модель — Fun Driven Developmant, это когда вы всей командой кайфуете от новых фич, когда баги такие что штырит их раскопать, задачи такие что на первый взгляд кажется что это невозможно, зато потом когда это работает прям шик. Уже 10 лет так, за небольшими скучными периодами исключениями. Геймдев. Правда при этом я перестал играть в игры, как свои так и чужие.
                                      0
                                      Fun это круто
                                        +2

                                        Есть ещё другая интерпретация — fu**up driven development.

                                        +2
                                        Наши разработчики подсказали еще CDD — Crunch-Driven Development
                                          +4

                                          Основные постулаты:
                                          Инкостыляция — сокрытие смысла костылей путем неоставления комментариев. Если любой разработчик может изменить твой костыль — это небезопасно и вы должны всеми способами этого избегать.


                                          Наследование костылей — здесь всё ясно. Если вы до сих пор не выделили костыли в иерархию и не написали своей библиотеки костылей — вы ничего не знаете про CDD.


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

                                          0

                                          А как же SDD StackOverflow-Driver-Development?


                                          TDD — Type Driven Development

                                          Можно TypeDD. Т.е. все, кто пишет на языках со строгой статической типизацией, уже ее используют?

                                            0

                                            Нет. Если начинаете писать исполняемый код, пока не опишите все типы, то не используете.

                                              0

                                              В Ъ TDD до исполнения кода не доходит, достаточно того, что он тайпчекается.

                                                –1

                                                Но писать-то его все равно надо.

                                                  0

                                                  Не всегда. Есть тактики, есть elaborator reflection, да и можно код генерировать. map я вам могу написать и на идрисе, не написав ни буквы кроме имени функции и ее типа.

                                                  0

                                                  Ъ TDD — это, в смысле, труЪ TDD?

                                                0

                                                Если в вашем языке/IDE есть команда obvious proof search, сама находящая терм, удовлетворяющий типу, то точно используете.

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

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

                                                    +1

                                                    На качестве продукта отражается наличие сеттеров в принципе. :) Шутка с долей шутки :(

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

                                                      Мне кажется из TDD этого не следует. Т.е. сеттеры обычно покрываются в любом случае но не специально предназначенными для этого тестами. Что с TDD что без него.

                                                        0
                                                        Вам не кажется. В нормальных книгах по TDD, в том числе в книгах от его создателей, всегда пишется что не нужно писать тесты на вообще весь код. Тесты пишутся перед кодом, но только перед тем, для которого они нужны. Если у вас обычный сеттер без логики — вы пишете сеттер безо всяких тестов. И даже если в будущем вам понадобится такой код отрефакторить, то по TDD вам всего лишь нужно будет написать тесты перед рефакторингом, нет необходимости иметь тесты изначально если они не были нужны. Я даже видел, правда цитату вряд ли смогу найти, что и на код с логикой тесты нужны далеко не всегда, но тут граница конечно сильно размыта.
                                                          +1
                                                          Если у вас обычный сеттер без логики — вы пишете сеттер безо всяких тестов.

                                                          В моем предcтавлении в классическом TDD не пишут код, пока не упал тест. То есть сеттер я не могу написать без упавшего теста.
                                                          Но обычно сеттер нужен не для того, чтобы установить какое-то значение и радоваться этому. А чтобы это как-то повлияло на поведение.


                                                          Т.е. я пишу тест "если превышена максимальная глубина стека то выдается эксепшн" а не "если я задаю максимальную глубину стека, то она задана"

                                                            0
                                                            Цитату я сходу найти не могу, но то что видел по этой теме я — куча копированных методичек «Тесты всегда, никаких исключений» и цитаты от авторитетных программистов, в том числе создателей собственно TDD о том, что вполне можно написать простой код и без тестов. Суть не в том что без упавшего теста не пишется никакой код, суть в том, что без упавшего теста не пишется только относительно сложный код для которого в принципе тесты нужны. Я не претендую на истину в последней инстанции, но мне такой подход кажется гораздо более разумным и практичным. Но приходится иногда думать нужны ли для этого куска кода тесты и дописывать их если ошибся и решил что не нужны.
                                                              0

                                                              С моей точки зрения, если для чего-то не пишутся тесты, то для разработки этого не используется TDD.

                                                                0
                                                                Ну это уже философия. Если вы для 3х методов класса тесты пишете, а для 4го, который, например, всего лишь однострочная обертка библиотечной функции — нет, то используете ли вы для разработки TDD? А если вы именно по принципам TDD которые описывают его применимость определили что для этого метода тесты не нужны, то использовали ли вы его для разработки?
                                                                На самом деле я не вижу практической пользы от ответов на эти вопросы. И я точно знаю что фанатизм до добра не доводит и нужно понимать где и как применять методики.
                                                                  0
                                                                  Если вы для 3х методов класса тесты пишете, а для 4го, который, например, всего лишь однострочная обертка библиотечной функции — нет, то используете ли вы для разработки TDD?

                                                                  Да. Если я использовал для гвоздя молоток, а для шурупа отвертку, то я использую молоток.


                                                                  А если вы именно по принципам TDD которые описывают его применимость определили что для этого метода тесты не нужны, то использовали ли вы его для разработки?

                                                                  А вот тут я бы хотел ссылочку. Я слышал принцип "Тестировать надо то, что может сломаться". В моем представлении тестировать надо то, тестирование чего окупается (легко тестировать или выигрыш от предотвращения багов и влияния на дизайн большой).

                                                            0

                                                            Я если и тестирую геттеры/сеттеры то косвенно, при тестировании других фич. Ну типа в тесте на глубину стека пишу сначал $obj->setStackSize(0); $obj->doSomething(); и т.д. ТО есть без сететра код теста просто не запустится, а без нормальной реализации остальные тесты буду падать

                                                      0
                                                      не хватает ещё Bug Driven Development wiki
                                                      хотя это похоже на PDD.
                                                        0
                                                        А про Money Driven Development напишет кто-нибудь? Ведь реально работающий паттерн!
                                                          0

                                                          Очень мало разработчиков по нему работает в наших широтах: большинство на окладе и в коммерческой успешности разрабатываемого продукта заинтересованы поскольку постольку.

                                                          0
                                                          Может тест, а потом код это и хорошо, но когда заказчик за 3 часа меняет 8 раз все что он себе напридумывал, то как говорил Хой: — Я замучился тесты переделывать!

                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                          Самое читаемое