AgileDays-2009 (Technical excelence)

Материал из CustisWiki
Перейти к: навигация, поиск

Представляем краткий отчет и обзор докладов, прошедших на третьем, техническом треке «Technical excelence» конференции AgileDays.ru.

Вообще, мы (Стас Фомин и Андрей Бибичев) осуществляли организационно-техническую поддержку докладов в секции «Technical excelence», в частности, мы сняли и публикуем обработанное видео. Сделали что смогли — цветокоррекция, темпоральная фильтрация шумов, усиление границ (для большей читаемости слайдов), в звуке — нормализация и динамическая компрессия. Некоторую реверберацию (эхо), увы, убрать не удалось (уж очень это трудоемко), сорри.

Видео публикуем и в виде флешвидео (640x512) и отдельно можно скачать видео в оригинальном качестве (720x576). Мы специально оставили изображение слегка вытянутым — и максимум площади из максимально возможного квадрата 640x640 используется, и буквы читаются легче, и люди стройней и симпатичней). Для пары докладов «лекционного» типа, не сильно зависящих от слайдов, мы сделали и аудиоподкасты.

Да, если судить о докладах третьего трека по оперативным отзывам в микроблогах, то отзывов о докладах с остальных треках больше, но это не потому, что доклады тут были самые унылые — просто организованный бесплатный WiFi не добивал до третьего этажа, где проходил трек «Technical excelence», а писать отзывы с мобильников все-таки у нас не так много энтузиастов. К тому же, отзывы в твиттер о конференции, на уже выходят из моды, см. Совет № 3.

Обзор Agile

Докладчик
Никита Филиппов

Какая конференция Agile без основного доклада по методологиям? Этот доклад будет отправной точкой для тех, кто пришел послушать об Agile, кто планирует внедрять Agile в своем проекте или организации, или для тех, кто хочет сравнить свои способы работы с лучшими практиками индустрии. Главной целью моего доклада является достижение понимания всех участников конференции, что такое Agile.

На этом докладе мы рассмотрим:

  • Плюсы и минусы других процессных подходов: Waterfall, Code & Fix.
  • Принципы Agile: Anti-code & fix, Anti-Waterfall
  • Практики Scrum
  • Чем можно улучшить Scrum?


Это собственно изложение азов ценностей и практик Agile-движения и SCRUM-а в частности, и несмотря на азбучный уровень, доклад оказался весьма полезным. Ведь с одной стороны, на конференции с названием AgileDays, да еще проводящейся не в первый раз, да еще и по теме, которой вроде как уже несколько лет общеизвестна в индустрии, можно было бы ждать, что «все в теме», и «буквари» вроде как издевательство над аудиторией. Но судя по вопросам, в зале было полно людей из параллельных вселенных «мира Дилберта и роговолосых», так что этот доклад оказался незря.

Так что если вы «в теме» — то, скорее всего, ничего нового их этого доклада вы не узнаете. А вдруг слова «Agile» и «SCRUM» незнакомы (или знакомы, но в сомнительном изложении типа «слышал я Карузо…, Рабинович вчера напел…») — то посмотрите или послушайте. «Послушайте» — в смысле эту лекцию можно слушать даже без слайдов — мы выложили подкаст:


Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Обзор Feature-Driven Development и Domain-Driven Design

Докладчик
Андрей Бибичев

Эрик Эванс (Eric Evans) в своей книге о Domain-Driven Design (DDD) пишет: «Software development is all design» (Разработка ПО — это всецело дизайн/проектирование). И правда: ведь сборка ПО целиком автоматизируется и не требует ощутимых усилий со стороны проектной команды.

И что же в Agile есть на тему дизайна/проектирования? Scrum об этом молчит. В eXtreme Programming (XP) есть такие практики, как Test-Driven Development (TDD) и Refactoring, но они работают, скорее, на уровне дизайна отдельных классов и их имплементации («микро-дизайн»). А как же быть с архитектурой и «макро-дизайном»?!

«Лучшие собаководы» (гуру архитектуры и проектирования) рекомендуют сочетать проектирование сверху-вниз и реализацию снизу-вверх, то есть макро- и микро- дизайны. Agile-процесс под названием Feature-Driven Development (FDD) как раз базируется на таком подходе. В докладе дается краткое описание как самого процесса, так и его истории. Проводятся параллели с XP и Scrum, дается анализ сильных и слабых сторон, а также области применимости.

Казалось бы, причем здесь Domain-Driven Design (DDD)? В FDD краеугольным камнем является модель предметной области (Domain Model). В DDD — тоже. Но если FDD — это прежде всего процесс, то DDD является подходом к проектированию и реализации, причем этот подход замечательно сочетается с любым Agile-процессом. Кроме того, в DDD много внимания уделено «сшивке» макро- и микро- дизайнов: описаны общие принципы имплементации модели в программном коде, приводятся готовые образцы (patterns) реализации.

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

Андрей убеждал не останавливаться на тупом, «карго-культовом», внедрении SCRUM-практик, уподобляясь кальсонным гномам, а обязательно развивать архитектурные практики, такие как Domain-driven design и Feature Driven Development, настаивая, что для достаточно большого проекта (от 20 человеко-лет) это не «модное дополнение к SCRUM», а именно необходимый ингридиент.

В целом, аудитория была в теме — достаточно заметить, что на конференции был десант из Нижегородского Интела, где ребята выступали с близким по теме докладом #TDD + DDD + MVP + GoF + PoEAA= Love!, так что четверть часа после доклада шла дискуссия (есть на видео), на темы:

  • Как избежать анемии доменной модели и бизнес-логики — классически инкапсулировать бизнес-логику в объекты или выносить ее на сервисный слой?
  • Как должны соотноситься уровень Infrostructure и Domain? Должен ли Domain классически использовать Infrostructure (возможно разделяемую на несколько проектов с разными предметными областями), или, в соответствии с новыми веяниями использовать паттерны «Inversion of Control/Dependency Injection», и Domain ничего не должен знать о Infrostructure, что несколько необычно, но должно давать большой буст при тестировании (можно разгонять тесты, mockiруя тяжелый инфраструктурный слой).
  • Оправдано ли экономически, играть во все игры с модными паттернами и практиками — понятно, что все это ради качества, но какой ценой? Может это могут позволить себе только очень богатые компании, для inhouse-разработки, или крупные компании для продуктов с огромными тиражами, но ведь в обычной заказной разработке дилемму «скорость-качество», невыгодно радикально решать в пользу последней.

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

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Увидеть лес за деревьями

Докладчик
Стас Фомин (CustIS)

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

Однако на практике возникает проблема — как быстро и эффективно исследовать этот пласт информации?

  • Читать логи переписки и коммиты в VCS? То есть разрабатывать «шахту знаний» киркой и мотыгой? Бродить по лесу и считать деревья?
  • Посчитать метрики? Ненавистные SLOC и иже с ними? В зависимости от глубины детализации можно получить:
    • либо пару унылых метрик («KSLOCs в месяц на сферического разработчика в вакууме», то есть в нашей метафоре максимум — «площадь лесного массива»),
    • либо многостраничные Excel-dashboardы, заполненные мириадами цифр, в которых почти также бессмысленно лезть человеку, если он не профессор Чарли Эппс из сериала Numb3rs с его верными суперкомпьютерами и волшебными алгоритмами DataMining-a.

Что же делать?

Есть альтернативный способ «увидеть лес за деревьями» и при этом выжать краткую информацию по процессу — Визуализация.

Итак,

  • Мы покажем модель визуализации коллективной разработки ПО.
  • Представим portable-фреймворк для такого исследования, адаптированный для максимальной простоты использования — все работает из коробки, просто скормите ему вашу историю.
  • На выходе — музыкальные ролики визуализации! Их можно смотреть как с исследовательскими целями, так и для удовольствия, радуя себя, команду, и, возможно, приманивая новых сотрудников.
  • …
  • PROFIT! Фреймворк раздадим всем бесплатно, и никто не уйдет обиженным!

Собственно, все, о чем был доклад, мы выложили в open-source, и все это можно свободно и быстро попробовать (скачать и запустить на любом проекте — работает из коробки) — ShowTeamWork.

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Внедрение Agile

Докладчик
Павел Афанасенко

Вы узнали про Agile и загорелись — захотели внедрить у себя в команде. Но как это сделать — ваша ситуация не совсем похожа (а иногда и совсем не похожа) на ту, которую описывают в своих статьях и презентациях евангелисты Agile движения. Как преодолеть сомнения? Как начать? Как избежать ошибок на непростом пути внедрения Agile и придти к успешному результату?

Я внедряю Agile вот уже на протяжении 7 лет в командах и организациях разного калибра, находясь при этом на разных ролях: рядового разработчика, тимлида, приглашенного консультанта и менеджера проекта. Независимо от бизнеса компании, разрабатываемого продукта, размера команды, роли адепта Agile в команде и массы других факторов, внедрение Agile происходит по одному общему сценарию, проходит определенные этапы. На пути внедрения возникают типичные ловушки, в которые можно попасть и увязнуть, и уже наработаны методики выявления и преодоления таких ловушек. Этому и посвящен мой доклад.

Докладчик — известный консультант по вопросам внедрения Agile-практик (SCRUM, eXtreme programming,…), рассказал о нетривиальных проблемах реального внедрения этих практик. Кстати, эту лекцию тоже можно вполне прослушать в отрыве от слайдов:


Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

8-битный Scrum

Докладчик
Алексей Омельянчук (Сигма-ИС)

Можно ли использовать гибкие методологии на предприятиях по производству микроконтроллерных устройств? Оказывается, можно!

Представьте, что разработка включает в себя не только написание ПО, но и создание аппаратной платформы, на которой оно будет исполнятся. Более того, процессоры преимущественно используются 8-разрядные, а языки разработки — ассемблер и «чистый» С. Как использовать в этом случае Scrum?

Автор доклада обобщит свой опыт внедрения Agile в трех различных компаниях:

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

Для всех 3-х предприятий характерна выраженная специализация разработчиков, необходимость синхронизации разработки аппаратной и программной части и «размазанный» по нескольким командам Product Owner.

Автор расскажет о том, что сработало, а что не получилось и о том, как помогло применение отдельных методов Lean Development и максимальный упор на раннюю полномасштабную демонстрацию.

Обычно, при словах SCRUM всплывает некоторый стереотип — программисты пишут заказной софт (информационная система, скорее всего с вебинтерфейсом) на основе мощных библиотек и фреймворков, легко удовлетворяя метания бизнес-пользователей за счет заложенной гибкости архитектуры, наслаждаются кроссфункциональностью (в смысле смеются, когда дизайном занимается хардкодер, но в целом все ОК), с энтузиазмом играют во все developers games (ибо в РФ, программист — пока профессия молодых).

А что если нет не то, что лишних пары гигабайт для вечноголодной Жавы, а вообще, есть только 512байт ПЗУ и 32 байт ОЗУ? А если рабочий стол программиста занят не тремя 24" мониторами, а тестерами (в смысле приборами, а не девушками), осциллографами и паяльником? Если специалисты настолько матерые и узкие, что о кроссфункциональности не может быть и речи, а из-за их возраста «standup meetings» приходится отказать?

Not Invented Here-2009-05-04.jpg
Not Invented Here-2009-05-05.jpg

По опыту докладчика (на основе работы в трех различных производствах, связанных с микроэлектроникой), в таких условиях SCRUM постепенно мигрирует к Lean-практикам, типа Kanban, но некоторые практики SCRUM сохраняют свою ценность в любых условиях.

Например, частые демонстрации. Интересно, судя по вопросам, в зале были специалисты из микроэлектронной индустрии, и на их жалобы вида «Как делать регулярное демо (нового прибора), если поставщик только через квартал сможет дать нужную деталь (индикатор)» — докладчик парировал — «Стыдитесь! Для демонстраций и тестирования используйте mock-объекты подключите обычный компьютер с симулятором».

Из отзывов наших сотрудников:

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

Команда его прошла путь от производственного предприятия работающего на МО с жестким Rational Unified Process, через крупного частного производителя контроллеров (крупнейший поставщик АвтоВаза, 2 млн штук в год) до software-предприятия, занимающегося, в основном, программированием, а не железом. На каждом этапе добавлялись новый практики.

Что используются

  • спринты, ограниченные во времени
  • демо (по признанию докладчика практика оказалась самой полезной)
  • планирование. Причем, планируют 120—140 % от запаса времени, с разделением на обязательное и бонусы

Длительность спринта составляет 1 месяц, что было связано со сложившимся на предприятии укладом. Также был «мегаспринт» — 3 месяцы. Эта цифра обусловлена

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

Еще одна особенность — сборные команды. Каждый проект ведется максимум двумя людьми (большему количеству просто нечего делать на устройстве, куда влезает 500 строк ассемблера), команды объединяют несколько проектов. Ни о какой кросс-функциональности речь не идет (одна настройка рабочего места занимает день-два), но таким образом все-таки немного смягчаются риски того, что в случае болезни одного человека, его будет не кем заменить. Scrum-митинги из-за этой специфики проходят на по 15 минут раз в день, а большее время раз в неделю, чтобы было время въехать в чужую предметную область.

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

ОО дизайн: SOLID принципы

Докладчик
Дмитрий Кандалов (Deutsche Bank)

В этом докладе я расскажу о SOLID принципах ООП описанных Робертом Мартином (Robert C. Martin) в книге «Быстрая разработка ПО: принципы, паттерны, практики» (Agile Principles, Patterns, and Practices) и что они означают в реальной жизни. Некоторые из этих принципов широко известны в других формах, некоторые очевидны. Но их интерпретация Робертом Мартином одна из лучших и может быть очень полезна для программистов использующих ОО языки.

Докладчик рассказал о наборе принципов софтверного проектирования, скрывающихся за акронимом SOLID:

Кстати, если скучно читать эти сухие определения, то посмотрите на набор веселых «демотиваторов» по этой теме. А докладчику дарим бесплатную идею — при следующем выступлении, добавить эти демотиваторы к слайдам.

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

MS Team System vs IBM Rational Jazz: лучший инструмент разработчика

Докладчики
Евгений Злобин (Microsoft) и Тимур Маркунин (IBM)

Как следует из названия, ожидалась совместная презентационная сессия сейлов Microsoft и IBM. Те, кто в кулуарах даже ожидали sales battle, боюсь были несколько разочарованы — никакого экстремального маркетинга не случилось, была последовательная презентация близких по смыслу продуктов, но никакой войны — докладчики очень благожелательно относились друг к другу, иногда даже в ответах на вопросы рекомендуя продукт конкурента.

В некотором смысле разгадка проста. Продукты эти весьма недешевы, причем живут в разных нишах — продукт от IBM, где-то на полпорядка дороже продукта от Microsoft. Так что далеко, не все считают оправданным их приобретение. Да и что говорить, в отличие от 90х годов, где в РФ доминировал («условно-бесплатный») стек разработки от Microsoft (великолепная для своего времени MVS6 — MVC6, MVB6 и т.п.) что соответственно определяло и выбор инструментов (SourceSafe и т.п.), сейчас огромное количество прекрасных бесплатных инструментов организации разработки.

Например, сердцем любого «уникального набора интегрированных систем поддержки разработки» является VCS — система контроля версий. Внутри TFS находится форк известной коммерческой VCS Perforce. Но сейчас появилось много классных централизованных и распределенных систем контроля версий, бесплатных и к тому же open-source, очень активно развивающихся. Недавно мы провели опрос об используемой VCS на центральном IT-портале, где ответило более двух тысяч человек и выяснилось, что коммерческими VCS (подсчет абсолютно по всем вендорам) пользуются менее 4% разработчиков, а в майнстриме среди централизованных VCS — Subversion, а среди распределенных VCS — Git.

Кстати, рекомендуем почитать наши переводы статей о современных системах контроля версий.

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

TDD + DDD + MVP + GoF + PoEAA = Love!

Докладчик
Антон Бевзюк (Intel)

Наша команда имеет более чем 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. По результатам этих проверок наш проект получил высокие оценки процесса и продукта.

Краткое резюме описываемого проекта в цифрах (в стиле заставки сериала «Numb3rs»:

  • 2 года
  • 12 разработчиков
  • 50 человеко-лет (нет, вдумайтесь — это целая человеческая жизнь, по крайней мере, в разумном возрасте, среднего мужчины в РФ)
  • 32 проекта в solution’е Visual Studio
  • 3-хзвенная архитектура (WebForms/WinForms-клиент и MSSQL)
  • 140000 строк
  • 100000 из них — это строки 5000 тестов
  • 20 экранных форм
  • 10 Гб БД.

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

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

Из отзывов наших сотрудников:

С точки зрения архитектуры подход Intel’а отличается от книжного DDD, который описывал в своем докладе и Андрей Бибичев (например, если почитать тут ). Используя принцип 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. Например, вот такое: 

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)
    }
 
}

…Много обсуждаемая в форумах по архитектуре (например, здесь) проблема — как отделять домен от инфраструктуры доступа к данным так, чтобы это было красиво и удобно. Они для этого активно используют паттерн Specification с возможностью сложных операций над спецификациями.

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

Кстати, повторимся, дискуссия о «правильном DDD» продолжилась и в онлайне. Присоединяйтесь к ней, если есть конструктивные замечания.

К сожалению, видео не совсем полное, мудак-оператор (я, Стас Фомин), куда-то задевал конец выступления. Сорри!

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».


Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Источник — «http://lib.custis.ru/index.php?title=AgileDays-2009_(Technical_excelence)&oldid=31942»