Просмотр исходного текста страницы TDD + DDD + MVP + GoF + PoEAA = Love! (AgileDays-2009)

== TDD + DDD + MVP + GoF + PoEAA = Love! ==
;Докладчик: [http://users.livejournal.com/_flykin_/ Антон Бевзюк] (Intel)
* http://www.slideshare.net/Nfilippov/tdd-ddd-mvp-go-f-po-eaa-love

----
<small>
Наша команда имеет более чем 6-летний опыт использования гибких методологий.

За это время мы разработали десятки бизнес-приложений. Мы используем передовые практики (Scrum, XP, Kanban) и шаблоны (GoF, PoEAA), доказавшие свою эффективность.

Мы расскажем о том, как мы «поженили» все это разнообразие в одном финансовом приложении.
Это приложение спроектировано по Domain-Driven Design (DDD), разработка ведется в строгом следовании парному программированию. Test-Driven Development (TDD) обеспечивает 100 %ное покрытие тестами бизнес-логики, а применение шаблонов MVP и Model-View-Viewmodel позволяет протестировать презентационную логику unit-тестами без применения внешних инструментов для тестирования интерфейса.

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

Отличительной особенностью нашего кода является то, что он вообще не содержит комментариев без ущерба для понимания. Код самодокументирующийся. Мы активно используем DSL для упрощения написания тестов. К настоящему моменту система содержит 4500+ тестов, которые выполняются не более 1 минуты.

Наш доклад раскрывает ряд best practices в области программной инженерии, например:

* Автоматизированный деплоймент (на развертывание приложения уходит около 10 минут, делается это одним кликом).
* Специализированные парные станции
* Совместное использование всех практик XP (синергетический эффект)
* ''Kaizen'' (постоянный пересмотр как процесса разработки, так и самого кода)
* Элементы fun’а

В этом году мы успешно выдержали внешний и внутренний аудиты, нацеленные на анализ качества кода и оправданность использованных нами решений. Внешний аудит проводился специалистами Microsoft. По результатам этих проверок наш проект получил высокие оценки процесса и продукта.
</small>
----

{{slideshareembed|tdddddmvpgofpoeaalove-091215035619-phpapp02|640|480}}

{{vimeoembed|8333707|640|512}}

Краткое резюме описываемого проекта в цифрах (в стиле заставки [[RuPedia:Numb3rs|сериала «Numb3rs»]]:
* <tt>2</tt> года
* <tt>12</tt> разработчиков
* <tt>50</tt> человеко-лет (''нет, вдумайтесь — это целая человеческая жизнь, по крайней мере, в разумном возрасте, среднего мужчины в РФ'')
* <tt>32</tt> проекта в solution’е Visual Studio
* <tt>3</tt>-хзвенная архитектура (WebForms/WinForms-клиент и MSSQL)
* <tt>140000</tt> строк
* <tt>100000</tt> из них — это строки <tt>5000</tt> тестов
* <tt>20</tt> экранных форм
* <tt>10</tt> Гб БД.

{{note}} По нашим меркам, это совсем небольшой проект, с удивительно большими затратами людских и временных ресурсов. Впрочем, читателю лучше сделать самостоятельное сравнение с своими проектами, а для подсчета различных SLOC-метрик рекомендуем использовать утилиту [http://cloc.sf.net CLOC].

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

Из отзывов наших сотрудников:
----
<small>
С точки зрения архитектуры подход Intel’а отличается от книжного DDD, который описывал в своем докладе и Андрей Бибичев (например, если почитать [http://www.infoq.com/minibooks/domain-driven-design-quickly тут ]).
Используя принцип ''Inversion of Control'', они изолируют сборку с классами домена от инфраструктуры. Таким образом, домен у них не зависит ни от чего, и поэтому хорошо портируется, тестируется, и легко переносит существенные изменения инфраструктуры. Именно это, «чистый домен», они и ставят во главу угла своего подхода.

…Ребята также показались TDD-экстремистами, не знаю насколько это хорошо или плохо. Их мантры такие
* Подумай->Напиши тест, который падает где ты ожидаешь -> Сделай минимальное исправление
* Assert, по-хорошему, должен быть один, а исправление — минимальным. Если это не так, скорее всего нужен еще один тест.

… Все-таки они там TDD-маньяки и стремятся оттестировать все, что можно, и что нельзя. С тестированием «чистого домена» все более-менее просто, а дальше они начали тестировать GUI. По опыту прошлых проектов было известно, что ручное и скриптовое тестирование малоэффективно и мучительно. Поэтому они начали думать, как приспособить инструменты и методики ''unit''-тестирования к тестированию GUI. Для этого они начали пересматривать архитектуру GUI-слоя (как неоднократно звучало, TDD — это не тесты, это методика проектирования!)

… Докладчики рассмотрели несколько паттернов устройства GUI (''ModelViewController -> ModelViewPresenter -> ModelViewViewmodel''). Собственно, смысл этого сводится к тому, чтобы сделать View единственной и максимально простой, зависящей от платформы частью паттерна, а все остальное — покрыть тестами.

… Я так понял, что этот подход позволил им достаточно безболезненно перевести клиента с WinForms на WebForms. С замечанием из зала о том, что для Web-интерфейса с активным использованием JavaScript’а на клиенте такой подход не работает, докладчикам пришлось, …, согласиться.

… Докладчики с гордостью заявляли, что стараются тестировать все, что может сломаться и с чем бывают проблемы: код, конфигурации, хранимые процедуры, даже связывание (''binding'') GUI. Любопытно, что в тестах они проповедуют принцип «1 тест — 1 assert». Мне не очень понятно, как это можно реально соблюдать, не впадая в безумное дублирование, и какой в этом смысл. Книжное «сразу понятно, что сломалось» смешно — нам почему-то и без этого принципа обычно понятно, что сломалось.

…Реализация DDD-подхода в данном случае состоит в том, что domain описан в отдельной сборке, которая является полностью независимой. Для обеспечения независимости используется прием ''Inversion-of-Control'' и одноименная библиотека.
* Плата за такой чистый дизайн велика — для каждого типа доменный модели нужен еще тип, реализующий для него работу с базой
* Зато 5000 тестов работают одну минуту.

…Действительно впечатляющие данные — 5000 тестов у них выполняются за минуту.
Около 200 тестов, все-таки требующих наличия БД, у них выполняются минут за 10 и их запускают нечасто.

…Тесты, как известно, должны быть максимально простыми и выразительными. Поэтому они активно используют в тестах всякие практики типа ''FluentInterfaces'', а также забавные методы-расширения, например, для задания дат в виде 11.12.of2009().

… При написании тестов использует свои ''embedded DSL''. Например, вот такое:
<code-csharp>
var testDate = 11.12.of2009

public static class DoubleExtensions
{
    public DateTime of2009(this double date)
    {
        return new DateTime((int)date.Floor(), (int)(date-date.Floor())*100, 2009)
    }

}
</code-csharp>

…Много обсуждаемая в форумах по архитектуре (например, [http://rsdn.ru/Forum/MsgList.aspx?group=design здесь]) проблема — как отделять домен от инфраструктуры доступа к данным так, чтобы это было красиво и удобно. Они для этого активно используют паттерн ''Specification'' с возможностью сложных операций над спецификациями.

…Не со всем хочется согласиться, но заставляет задуматься, что можно улучшить в наших системах с точки зрения общей архитектуры/тестопригодности. Выкладывать свой ''framework'' как пример архитектурного паттерна они отказываются, ссылаясь на коммерческую тайну.
</small>

----

Кстати, повторимся, дискуссия о «правильном DDD» продолжилась и в [http://users.livejournal.com/_flykin_/101026.html онлайне]. Присоединяйтесь к ней, если есть конструктивные замечания.

{{caution}} ''К сожалению, видео не совсем полное, мудак-оператор (я, [[Участник:StasFomin|Стас Фомин]]), куда-то задевал конец выступления. Сорри!''

<noinclude>{{ActualBanner2}}</noinclude>

[[Категория: AgileDays-2009 (наша запись)]]
[[Категория: Программирование (доклады)]]
[[Категория:Архитектура (доклады)]]
{{replicate-from-custiswiki-to-lib}}