Всего какой-то месяц назад (23-25 апреля) в славном городе Будапешт прошла конференция для разработчиков CRAFT. Мне посчастливилось на нее попасть и вот теперь дошли руки написать отзыв об увиденном и услышанном.
Конференция заманила к себе не тем, что можно за корпоративный счет выбраться в Европу, а подборкой приглашенных авторов, среди которых были Dan North, Michael Feathers, Bruce Eckel, Eric Evans, Greg Young. Странно, что о ней не было упоминания на хабре. Не смотря на то, что конференция заявлялась как конференция для разработчиков, она была совсем не о технологиях. Было несколько докладов про использование конкретных технологий, но большинство докладов было про разработку вообще.
Девизом конференции можно назвать призыв «Адаптируйся!». Эта мысль звучала в очень многих докладах. Может организаторы поэтому не выдали блокнотов в пакете участников — хотели, чтобы мы адаптировались? =) При этом выдали ручки и пришлось искать блокнот в окрестных магазинах.
Под катом описание и видео докладов, которые мне показались наиболее интересными.
Вставить видео прямо в статью не получилось, поэтому видео представлено ссылками. Если кто поможет со вставкой самих видео, то буду признателен.
Для себя я выделил несколько наиболее полезных и интересных докладов, а остальные расположил в хронологическом порядке.
Наиболее полезные и/или интересные доклады (очень рекомендую к просмотру)
How I Learned to Stop Worrying and Love Flexible Scope (Gojko Adzic)
Видео доклада
Очень содержательный первый доклад, который задал тон для всей конференции. Основная мысль: гибкие подходы применимы только там, где изменчивый внешний мир. Если внешний мир статичен по отношению к системе, то scrum вырождается в waterSrumfall, что влечет накладные расходы без дополнительного профита. Если же внешний мир недостаточно известен или быстро меняется, то надо уметь адаптироваться. Как пример, автор приводит опыт команды Дукати во время их дебюта на треке супербайка. В критической ситуации все гибко, потому что надо быстро адаптироваться, иначе не выживешь.
Как способ адаптации к ситуации автор предлагает пользовательские истории (User Stories).
Основная мысль: из пользовательских историй нужно составлять и использовать roadmap по ее прямому назначению: как "карту дорог". Автор говорит, что большинство виденных им roadmap представляли на самом деле туннель, а не карту дорог. Туннель предполагает движение только в одном направлении, а не множество вариантов путей. Как пример автор приводит автомобильный навигатор. Он идеален для планирования и ориентирования на местности, потому что показывает два основных информационных блока, описывающих текущую ситуацию:
- расстояние до следующего поворота;
- направление следующего поворота.
Дальше автор перешел к принципам Палчинского из книги Тима Харфорда Adapt: Why Success Always Starts with Failure: ссылка на цитату о принципах.
Автор показывает, что пользовательские истории нужно использовать для анализа того что заказчик на самом деле хочет, а затем для адаптации к текущей ситуации проекта. Не надо пытаться реализовать все истории, потому что это может быть либо не нужно, либо очень дорого. Вместо этого надо рассматривать пользовательские истории как набор альтернатив (карта дорог), которые можно выбирать при изменении ситуации вокруг проекта.
Говорил, что готовит к выходу книгу «50 quick ideas to improve your User Stories».
Architecture War Stories (Stefan Tilkov)
Видео доклада
Доклад из разряда «как так получается, что умные люди делают глупые вещи». Стоит смотреть, чтобы попробовать сравнить свое поведение с примерами. Примеры все жизненные с реальных проектов. В конце автору даже задали вопрос «а вы вообще работали на успешных проектах». Доклад очень легко смотрится из-за обилия примеров и интересных моментов, над которыми можно посмеяться.
Автор высмеивает архитектурные фейлы — решения, которые были приняты в разных проектах в разное время, в том числе и им самим. Рассказывает о том, как это решение рождалось, почему идея казалось крутой и почему воплощение идеи получалось ужасным. Большинство систем, о которых он говорит, используются в реальности. Автор делает лаконичные выводы о том, что нельзя делать или наоборот надо делать, чтобы избежать подобных проблем. Несколько основных тезисов (все не выписывал — без контекста они будут не понятны):
- Don't cache the cache.
- Data should be free of code dependencies.
- Fight the madness.
Jackstones: the journey to mastery (Dan North)
Видео доклада — к сожалению видео начинается примерно с 10-й минуты. В первой части Дэн рассуждает о том как профессионалы в разных областях упражняются в мастерстве.
Доклад о том как путешествовать к Мастерству и что такое Мастерство вообще. За основу взят рассказ про складывание оригами «Jackstone», который автор не мог сложить 15 лет.
Основное определение: Мастерство — это возможности в контексте. Про этот доклад сложно что-то рассказать, не пересказав его полностью. Рекомендую к просмотру всем, кому интересна тема совершенствования своего мастерства.
Acknowledging CAP at the Root — in the Domain Model (Eric Evans)
Видео доклада
Этот доклад был наиболее ожидаемым для меня — хотелось услышать про эти три буквы DDD из первых рук. Но, как ни удивительно, этот доклад оказался одним из самых нудных докладов на конференции. Может быть еще потому, что уже достаточно много знаю про это и мало что нового услышал из доклада. Эванс рассказывал совсем без эмоций, академическим тоном. Слушать было тяжело, но суть передавал достаточно ясно.
Первая часть доклада посвящена описанию того как важно правильно выделять агрегаты и их корни и как это может повлиять на работоспособность и живучесть системы в будущем. Рассказ базировался на примере с поставкой грузовых контейнеров через океаны и координацией расписания поставки. Показывал как в зависимости от выбора агрегатов и их корней меняется поведение системы и какие грабли получаются в каждом из случаев. Основные тезисы: правильно формулировать вопросы к системе и балансировать между нормализацией и денормализацией.
Неконсистентность между состояниями агрегатов — это нормальное явление и существует в любой сложной системе. Поэтому она должна регулироваться соглашениями (SLA), которые регламентируют как долго такая неконсистентность может существовать в системе.
В конце доклада немного затронул bounded context'ы. Между контекстами надо использовать Enevtual Consistencey.
Просто хорошие и интересные доклады в хронологическом порядке
Going Reactive: Event-Driven, Scalable, Resilient & Responsive Systems (Jonas Bonér)
Видео доклада
Хороший вводный доклад в принципы реактивного программирования и событийно-ориентированной разработки. Автор гооврит, что основной пробелмой реактивного программирования является большой порог вхождения, но после преодоления этого порога подход становится очевидным и простым. Основные тезисы:
- всегда надо использовать слабое связывание;
- проектировать надо так, чтобы не было блокировок никогда;
- проектировать надо асинхронное взаимодействие изначально;
- действующие лица общаются только посредством обмена сообщениями;
- использование Shared nothing architecture;
- прозрачность расположения;
Agility and the essence of software architecture (Simon Brown)
Видео доклада
Ничего не бывает бесплатно. За любое архитектурное решение приходится платить, поэтому нет идеальной абстрактной архитектуры. Гибкость архитектуры (как и системы) всегда относительна и зависит от времени. Поэтому всегда надо исследовать и адаптироваться.
Из-за разных интересов разных стейкхолдеров невозможно создать одну универсальную диаграмму. Совокупность диаграмм надо рассматривать как набор карт различного масштаба, в которых набор абстракций гораздо важнее набора нотаций. Предлагается использовать C4 модель:
- System Context
- Containers
- Components
- Classes
Мыслить надо в Компонентах, а реализовывать в Классах. Важно различать эти две точки зрения. Ну и в заключение, ключевой посыл от автора доклада: верните архитектуру обратно разработчикам!
What Makes a Good Development Process? (Bruce Eckel)
Видео доклада
Доклад о том, из чего собирается качество процесса разработки в общем. Не только написание кода, но вообще всего процесса. Доклад можно посмотреть, если месть минут 50 свободного времени. не смотря на очевидность основных тезисов, они не везде применяются, что приводит к плохим результатам. КО вещает:
- Использование репозиториев для версионирования, тестирования всего что можно тестировать и автоматизиации всего, что делается больше 1 раза, включая тесты.
- Коммуникация, честность и прозрачность на протяжении всего жизненного цикла проекта. В первую очередь перед заказчиком.
- Выпускать в минимально ценный продукт (Minimum Valuable Product). Но надо выпускать продукт, ценный для заказчика, а не для разработчика. Исходя из этого надо выстраивать приоритеты в решении конкретных задач.
- Автоматическая непрерывная доставка (Continuous Delivery), как механизм постоянного обновления версии. Это позволяет выпустить первую версию MVP как можно раньше и дальше дорабатывать по наиболее важным функциям.
- Ошибки неизбежны. На них надо учиться и адаптироваться (опять «Адаптируйся!»).
- BrainStorming заменить на BrainWriting. Во время BrainWriting участники в письменной форме высказывают свои мнения, а потом все собираются вместе и обсуждают. Это лучше, чем BrainStorming, потому что высказаться могут все, а не только самые горластые.
- Наиболее понятное и поддерживаемое решение является наилучшем выбором в большинстве случаев.
- Необходимо делать CodeReview.
McDonalds, Six Sigma, and Offshore Outsourcing: Unexpected Sources of Insight (Chad Fowler)
Видео доклада
Доклад от бывшего саксофониста, который стал разработчиком. Вводный доклад второго дня конференции, потому он о мире разработки в целом. О вдохновении и кураже при разработке, о качестве программного обеспечения, противоречиях во взглядах и целях разработчиков и заказчиков, которые рождают некачественные решения.
Автор упоминает о процессе разработки в залоге рассказа о Six Sigma, о том, что для заказчика важна Функция, а для разработчика — форма. Всегда идет противостояние внутреннего и внешнего качества. Здесь надо уметь балансировать, потому что внутренне качество определяет, но не всегда, внешнее. И вот это «не всегда» надо уметь выявлять.
Responsibly maximizing craftsmanship in software engineering (Theo Schlossnagle)
Видео доклада
Софт — отстой. Остальной доклад — объяснение этого тезиса и поиск причин, почему это так. основные причины:
- Разработка качественного программного обеспечения является очень сложной задачей (практически не выполнима).
- Инженеры подвержены «традициям». Здесь так принято и это работает, поэтому не трогай.
- Разработчики не читают академическую литературу и не знают азов.
- Команды внутри компании или даже проекта не делятся наработками.
- Инженеры отлично работают автономно (но в небольших проектах), поэтому в больших проектах возникают проблемы.
- Зачастую проще написать с нуля, чем рефакторить, но большинство предпочитает рефакторить.
Polyglot Data (Greg Young)
Видео доклада
Доклад о преимуществах подхода Event Sourcing перед традиционными нормализованными базами данных. Любая СУБД — отстой (Every database sucks!). Но каждая отстойна своим уникальным и неповторимым образом. Поэтому надо для каждой конкретной задачи применять подходящий для этой задачи инструмент. Хранение потока событий, вместо состояний позволяет добиться этого. Выделить конкретные тезисы у меня не получилось, ибо это уже был последний доклад во второй день конференции, но посмотреть доклад стоит.
Ну и доклады, на которые не стоит тратить свое время
Find the Right Abstraction Level for Your Tests (Gerard Meszaros)
Видео доклада
Для меня этот доклад был из разряда откровений Капитана Очевидности: делайте автотесты наиболее автономными. Тест должен тестировать одну частицу функционала на нужном уровне абстракции. Если выбран не тот уровень абстракции, то Автоматизация тестирования UI невозможна, потому что на UI надо смотреть, чтобы оценить его качество.
Data-Driven Software Engineering (Jevgeni Kabanov)
Видео доклада
Странный доклад. Набор слайдов со статистикой из Developer Productivity Report
Databases & Schemas in an Agile World (Andrew Godwin)
Видео доклада
Ожидал от доклада каких-то сакральных знаний о том как можно делать действительно гибкие базы данных, но все оказалось банально:
- используйте PostgreSQL, потому что он дает минимальное время на простой и блокировки при изменении схемы;
- схему надо модифицировать только в рамках транзакции;
- ну и предлагает использовать гибридные (часть данных в типизированных колонках, а остальные в blob полях в виде xml или еще чего-нибудь) схемы для оптимизации между гибкостью и скоростью.
Автор: CrazyViper
