что такое мдд в играх
ДД (ролевые игры)
Игровые классы, относящиеся к ДД, могут иметь защиту: выше средней (например, воины Тира в «Lineage 2», Warrior, Paladin, Death Knight — в «World of Warcraft»); среднюю (лучники Эура — «Lineage 2», Hunter — «World of Warcraft», разбойники Одала — «Lineage 2», Rogue — «World of Warcraft», Druid — «World of Warcraft») и низкую (магические классы, к примеру, волшебники Фео — «Lineage 2», Mage, Priest, Warlock — «World of Warcraft»), Воин-Физик — «Метин2»
ДД выполняет свои функции в тесном взаимодействии с танком, целью которого является отвлечение внимания противника на себя. Задача ДД — выждать момент, когда танк наберет достаточное количество ненависти противника («аггро»), после чего можно начать нанесение основного урона.
Зачастую ДД, в отличие от других бойцов, необходимо восполнение атакующего ресурса (маны, стрел, других игровых предметов), то есть по затратам он может быть достаточно дорогим персонажем, но есть и персонажи (например, Warrior, Druid, Rogue, Death Knight — «World of Warcraft»), которые используют ярость, энергию или силу рун как ресурс.
Так же есть два вида ДД — Рдд — Рэндж ДД (англ. range damage dealer), то есть персонажи, которые наносят урон с расстояния, и Мдд — Мили ДД (англ. melee damage dealer), то есть персонажи, которые наносят урон непосредственно стоя у цели.
В зависимости от типа группы, такого как ПвЕ\ПвМ — группа против игрового мира (англ. Party vs Environment\Party vs Mobs), ПвП — игроки против игроков (англ. Party vs Party\Player vs Player) или специализированные виды групп (мини и рейд), ДД выполняет различные функции, для которых основными параметрами являются мобильность или скорость персонажа (speed, agility) и высокий урон (damage или DPS).
За счёт высокого урона нескольких ДД группа может обходиться без танка, успевая уничтожать противников на расстоянии или за малый промежуток времени.
В большинстве игр ДД делятся на два класса: физический и магический урон. Первые в свою очередь разделяются на классы ближнего и дальнего боя, при этом обладая достаточно высокой защитой, а магические персонажи совмещают в себе возможности нанесения урона как с ближней, так и с дальней дистанции, при этом предпочитая не вступать в рукопашную схватку из-за малого запаса здоровья и слабой брони.
В отдельно взятой группе наличие ДД не обязательно, поскольку танк при поддержке саппорт-классов (хилеров (лекарей) и бафферов — персонажей, усиливающих урон или защиту) может самостоятельно справляться с одиночными противниками. Тем не менее, ДД — обязательная часть высокоуровневой группы, сражающейся с превосходящими по уровню, количеству или мощности врагами. Во-первых, наличие ДД значительно сокращает время уничтожения противника, во-вторых, ДД зачастую может наносить урон нескольким противникам сразу, в-третьих, на высоких уровнях мощность противников обычно уже превышает возможности одного персонажа, поэтому необходим сбор группы. В четвёртых, некоторые компьютерные противники обладают энрейнджем — через некоторый промежуток времени после начала боя либо после падения здоровья до определенного уровня их урон резко увеличивается, нередко превышая здоровье самого одетого танка в разы. Соответственно, в бою с такими мобами необходимы ДД.
В больших группах при наличии танка, или персонажа, выполняющего его функции, несколько ДД работают вместе «по ассисту» (англ. assist), выбирая следующую цель по его указанию. Обычно для этого существует специальный указатель (навык, умение). Сконцентрировав атаку на одной цели, ДД быстрее уничтожают группу противника, снижая при этом количество повреждений, наносимых при этом танку в единицу времени, таким образом экономя силы лекарей (ману).
* в указаниях классов «Lineage 2» использованы названия четвёртых профессий.
ДД (ролевые игры)
Из Википедии — свободной энциклопедии
ДД или дэмэдж дилер (англ. damage dealer ) — игрок в компьютерных или настольных ролевых играх, в группе либо индивидуально, наносящий в бою основной урон противникам («монстрам»). Его основной задачей является нанесение максимального урона за минимальное время. По-русски часто именуется просто «дамагер«, его основной характеристикой является ДПС (с англ. — «DPS», damage per second). [1] [2]
Игровые классы, относящиеся к ДД, могут иметь защиту: выше средней (например, воины Тира в «Lineage 2»; Warrior, Paladin, Death Knight — в «World of Warcraft»); среднюю (лучники: Эура — «Lineage 2», Hunter — «World of Warcraft»; разбойники: Одала — «Lineage 2», Rogue — «World of Warcraft»; или Druid в DPS-форме, в том же «WoW») и низкую (магические классы, к примеру, волшебники Фео — «Lineage 2», Mage, Priest, Warlock — «World of Warcraft»), Воин-Физик — Восточная action MMORPG «Metin2»
ДД выполняют свои функции в тесном взаимодействии с танком, целью которого является отвлечение внимания противника на себя. Задача ДД — выждать момент, когда танк наберет достаточное количество ненависти противника (т.н. «аггро», с англ. — «aggression») на себя, таким образом удерживая его (внимание) — после чего можно начать нанесение основного урона, при этом строго следя за тем, чтобы не обратить итоговое внимание противника лично на ДД, т. к. последнее может привести в итоге к уничтожению группы.
Зачастую ДД, в отличие от других бойцов, необходимо восполнение атакующего ресурса (маны, стрел, других игровых предметов), то есть по затратам он может быть достаточно дорогим персонажем, но есть и персонажи (например, Warrior, Druid, Rogue, Death Knight — «World of Warcraft»), которые используют ярость, энергию или силу рун как ресурс.
Так же есть два вида ДД — Рдд — Рэндж ДД (англ. range damage dealer ), то есть персонажи, которые наносят урон с расстояния, и Мдд — Мили(и) ДД (англ. melee damage dealer ), то есть персонажи, которые наносят урон непосредственно стоя у цели.
За счёт высокого урона нескольких ДД группа может обходиться без танка, успевая уничтожать противников на расстоянии или за малый промежуток времени.
В большинстве игр ДД делятся на два класса: физический (стрелковый и ближнего боя) и магический урон. Первые в свою очередь разделяются на классы ближнего и дальнего боя, при этом обладая достаточно высокой защитой, а магические персонажи совмещают в себе возможности нанесения урона как с ближней, так и с дальней дистанции, при этом предпочитая не вступать в рукопашную схватку из-за малого запаса здоровья и слабой брони.
В отдельно взятой группе наличие ДД не обязательно, поскольку танк при поддержке саппорт-классов (т. н. хилеров — лекарей, с англ. — «healers») и бафферов — персонажей, усиливающих урон или защиту) может самостоятельно справляться с одиночными противниками. Тем не менее, ДД — обязательная часть высокоуровневой группы, сражающейся с превосходящими по уровню, количеству или мощности врагами. Во-первых, наличие ДД значительно сокращает время уничтожения противника, во-вторых, ДД зачастую может наносить урон нескольким противникам сразу, в-третьих, на высоких уровнях мощность противников обычно уже превышает возможности одного персонажа, поэтому необходим сбор группы. В четвёртых, некоторые компьютерные противники обладают энрейнджем — через некоторый промежуток времени после начала боя либо после падения здоровья до определенного уровня их урон резко увеличивается, нередко значительно превышая здоровье самого прочного танка. Соответственно, в бою с такими мобами необходимы ДД.
В больших группах при наличии танка, или персонажа, выполняющего его функции, несколько ДД работают вместе «по ассисту» (англ. assist ), выбирая следующую цель по его указанию. Обычно для этого существует специальный указатель (навык, умение). Сконцентрировав атаку на одной цели, ДД быстрее уничтожают группу противника, снижая при этом количество повреждений, наносимых при этом танку в единицу времени, таким образом экономя силы лекарей (ману).
TDDx2, BDD, DDD, FDD, MDD и PDD, или все, что вы хотите узнать о Driven Development
Просматривая статьи по проектированию ПО, я постоянно встречал тучу невиданных сокращений и вскользь упоминаемых практик разработки.
Подходы к разработке делятся по сложности, областям применения и целям.
Думаю, настало время разобраться, зачем же они нужны, почему их так много, и как они могут быть нам полезны.
Мы начнем знакомиться с ними от самых простых до довольно сложных, рассмотрим примеры использования и плюсы и минусы каждого из них.
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?
Минусы:
Но у данного подхода есть и недостатки — это долго и дорого. 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:
Почему? В коде написано, что мы создали продукт странным образом и сохранили его. Как же все таки добавить продукт? Нужно его добавить. Вот DDD код:
Архитектура:
С точки зрения Domain-Driven Design абсолютно всё равно, какую архитектуру вы выберете. Domain-Driven Design не про это, Domain-Driven Design про язык и про общение.
Но DDD почти невозможен без чистой архитектуры проекта, так как при добавлении новой функциональности или изменении старой нужно стараться сохранять гибкость и прозрачность кодовой базы. Про порты, адаптеры и луковую архитектуру можно прочитать в отличной статье. Картинка сверху как раз из нее.
Про DDD также есть статьи, которые я очень советую прочитать внимательно — тут и тут.
Что же нам это дает в итоге:
Минусы:
FDD — Features Driven Development
FDD — Эта методология (кратко именуемая FDD) была разработана Джеффом Де Люка (Jeff De Luca) и признанным гуру в области объектно-ориентированных технологий Питером Коадом (Peter Coad). FDD представляет собой попытку объединить наиболее признанные в индустрии разработки программного обеспечения методики, принимающие за основу важную для заказчика функциональность (свойства) разрабатываемого программного обеспечения. Основной целью данной методологии является разработка реального, работающего программного обеспечения систематически, в поставленные сроки.
Как и остальные адаптивные методологии, она делает основной упор на коротких итерациях, каждая из которых служит для проработки определенной части функциональности системы. Согласно FDD, одна итерация длится две недели. FDD насчитывает пять процессов. Первые три из них относятся к началу проекта:
Последние два шага необходимо делать во время каждой итерации. При этом каждый процесс разбивается на задачи и имеет критерии верификации.
Давайте поподробнее остановимся на каждом пункте.
Разработка общей модели.
Разработка начинается c анализа широты имеющегося круга задач и контекста системы. Далее для каждой моделируемой области делается более детальный разбор. Предварительные описания составляются небольшими группами и выносятся на дальнейшее обсуждение и экспертную оценку. После одна из предлагаемых моделей или их совокупность становится моделью для конкретной области. Модели каждой области задач объединяются в общую итоговую модель, которая может изменяться в течение работы.
Составление списка функций
Информация, собранная при построении общей модели, используется для составления списка функций. Функции объединяются в так называемые «области» (англ. domain), а они же в свою очередь делятся на подобласти (англ. subject areas) по функциональному признаку.
Каждая подобласть соответствует определенному бизнес-процессу, а его шаги становятся списком функций (свойств). Функции представлены в виде «действие — результат — объект», например, «проверка пароля пользователя». Разработка каждой функции должна занимать не более 2 недель, иначе задачу необходимо декомпозировать на более мелкими итерации. Список свойств в FDD – то же самое, что и product backlog в SCRUM.
План по свойствам (функциям)
Далее идет этап распределения функций среди ведущих программистов или по командам.
Проектирование функций
Для каждого свойства создается проектировочный пакет. Ведущий программист выделяет небольшую группу свойств для разработки в течение двух недель. После оставляются подробные диаграммы последовательности для каждого свойства, уточняя общую модель. Далее пишутся «заглушки» классов и методов. В этот момент мы должны сфокусироваться на дизайне программного продукта.
Реализация функции
Пишем код, убираем заглушки, тестируем.
После того, как свойство протестировано и ушло в продукт, берем следующее по приоритетам свойство, повторяем цикл дизайна/реализации.
Итого, в результате мы получаем:
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) создание приложения состоит из следующих шагов:
Классический пример применения MDD, который используется уже давно, — моделирование баз данных. На основе одной концептуальной модели данных вы можете поддерживать несколько связанных с ней физических моделей для различных СУБД.
Какие преимущества мы получаем:
Минусы:
PDD — Panic Driven Development
Если вы пробовали методологии agile разработки, то вы наверняка пробовали и PDD. Давайте посмотрим более подробно, каковы принципы этой методологии.
Новые задачи приоритетнее старых.
Всякий раз, когда в середине спринта появляется новая проблема, она имеет приоритет над любой запланированной работой. Новое всегда лучше и имеет более высокий приоритет. Странно, почему это не стало одним из принципов гибкой разработки? Нацеленность на обеспечение ценности для клиента требует, чтобы команда заботилась о новых фичах и откладывала ранее определенную работу.
Пишите столько кода, сколько нужно, чтобы решить проблему.
Разработчики пишут код для жизни. Ошибки могут быть исправлены только кодом. Обсуждение дизайна и UX может только замедлить разработку. Но мы же не хотим терять драгоценное время? Сначала напишите решение, потом проверьте своё предположение по исправлению. Если исправление работает, проблема решена.
Тесты должны писаться в конце.
После того, как исправление внедрено, тесты могут быть запланированы как задача, которая будет сделана в будущем. Тесты полезны, но не являются приоритетными. Вы можете позаботиться о них позже. Ручного тестирования должно быть достаточно, чтобы доказать работоспособность реализованного решения.
Доверьтесь своему инстинкту.
Программирование — это искусство. Искусство имеет внутреннюю инстинктивную составляющую. Доверься своей интуиции. Напишите код. Разверните его. Только смелым улыбается удача.
Процесс гибок.
Любой процесс, созданный для разработки, тестирования и выпуска программного обеспечения, — это просто набор соглашений и правил, которые не высечены в камне. Критические исправления требуют разных подходов. Ожидается, что вы согнёте процесс, чтобы выполнить задачу в срок, если этого требует бизнес.
Это процесс, управляемый менеджером.
Как часть одной команды, менеджеры имеют право высказать свое мнение по вопросам развития. Рефакторинг или передовой опыт могут и должны быть отменены потребностями бизнеса. Инженеры могут высказать свое мнение, но они должны в конечном итоге принять любые потребности, которые приходят сверху.
Плюсы подхода:
Минусы:
PDD своеобразный антипаттерн разработки, который, к сожалению, мы все время от времени практикуем.
Заключение
Мир agile разработки многогранен. Мы познакомились только с малой его частью, рассмотрели достаточное количество практик разработки ПО, узнали об их преимуществах и недостатках.
Надеюсь многие из вас узнали что-то новое о Driven Development практиках и теперь, встретившись лицом к лицу с аббревиатурами DDD, BDD, MDD вы не испытаете замешательства, а может даже захотите попробовать их на практике.