Продолжаем череду online-митапов. Очередная встреча пройдёт при поддержке Райффайзенбанка 19 ноября.
Программа 49-й встречи
19.00 – 20.00 Андрей Сергеев. Dependency Pipeline
20.00 – 20.10 Перерыв
20.10 – 21.00 Станислав Продан. Создание и переиспользование модулей приложения при прототипировании
21.00 – 22.00 Круглый стол. Польза и вред прототипирования
Спикер: Андрей Сергеев
Тема: Dependency Pipeline
Описание
В современной промышленной разработке широко используется инверсия управления и внедрение зависимостей — как подход и как набор популярных Dependency Injection-фреймворков, которые, с помощью в том числе механизма рефлексии, обходят ограничения модели ОО-языков.
При работе с Dependency Injection у нас накопился ряд вопросов, вначале достаточно liteweight:
1. Целесообразно ли регистрировать в DI-контейнере все зависимости и позволять DI-механизму "прокидывать" зависимости через рефлексию в обход средств языка?
2. Хорош ли синтаксис популярных DI-фреймворков, в том числе встроенный в .NET, когда при регистрации зависимости в одном вызове указывается тип и скоуп зависимости (выглядит как смешение обязанностей)?
Далее, при продолжении работы, мы задались более серьезными вопросами:
3. Что можно сделать с ситуацией, когда в DI-контейнер беспорядочно "накидываются" зависимости, каждая из которых имеет зависимости (кроме конечных листьев этого DI-дерева) — по сути, имеем "разобранное" по вершинам дерево?
4. Как получить/создать такой DI-фреймворк, где дерево зависимостей будет восстановлено и наглядно описано в коде именно в виде дерева?
5. И, наконец, как при этом редуцировать количество внедрений зависимостей в "магический" DI-контейнер, работающий под капотом через рефлексию в обход средств языка, до минимально необходимого количества, достаточного для запуска приложения/сервиса (в идеале до одной зависимости — корня дерева зависимостей)?
В докладе мы расскажем, как мы прошли этот путь: задавались вопросами, нашли ответы и создали решение в функциональном стиле — Dependency Pipeline — готовое для стандартного DI-механизма .NET Core (а также которое может быть адаптировано для сторонних DI-решений, если они используются в .NET Core напрямую).
Также расскажем о том, как теперь, после внедрения Dependency Pipeline, мы регистрируем web-контроллеры с помощью наиболее общего механизма .NET Core, нежели предлагаемое по умолчанию более частное решение в типовом .NET Core-сервисе.
Помимо рассказа о непосредственно Dependency Pipeline, данный доклад, вкупе предыдущими докладами о Result и Result Pipeline/Flow, является прологом к серии докладов о "сервисе как конвейере" — Service as a Pipeline.
О спикере
Андрей — разработчик программного обеспечения в Райффайзенбанке.
Занимается проектированием и разработкой back-end платформ и продуктов, фокусируясь на дизайне архитектурных слоев и связей между ними: от ядра, движка, до уровней, реализующих в более высоких терминах предметные задачи, и далее до конечных точек. Использует актуальные .NET Core и C#, применяя в качестве основного функциональный подход — от использования языковых конструкций и принципа композиции до организации слоев в микросервисах и далее потоков данных и управления между сервисами. Обогащает подходы к разработке результатами анализа смежных и/или конкурирующих инструментов (F#, Java, Kotlin, Ruby, Go и др.) и принципов (например, динамической типизации). Исходит из первичности принципов, которые затем реализуются с помощью инструментов.
Спикер: Станислав Продан.
Тема: Создание и переиспользование модулей приложения при прототипировании
Последние продуктовые тенденции говорят нам, что тот, кто сможет запустить больше продуктовых экспериментов, быстрее узнает свою аудиторию и выиграет на максимально конкретном рынке мобильных приложений.
Что делать разработчикам в этом случае?
«Добавь быстренько кнопочку в этом месте, проверим гипотезу» — знакомая и в то же время нелюбимая фраза для многих разработчиков продуктовых команд.
Что в этой фразе бесит больше всего?
Во-первых, слово «быстренько». Часто это означает, что код будет написан не самым лучшим образом и, в угоду скорости, придется пренебречь большинством процессов.
Во-вторых, слово «гипотеза». Это означает, что если гипотеза не оправдается — мы должны будем удалить весь код. Но в худшем случае гипотеза оправдается, и придется очередной раз объяснять менеджеру, что этот код надо переписать перед раскаткой эксперимента на всех пользователей и вмердживании этого кода в мастер ветку.
Как я борюсь с этой фразой у себя на проекте?
Во-первых, я создал свою собственную библиотеку компонентов, которая позволяет мне «быстренько» собрать новое приложение, в которое при необходимости можно включить авторизацию, навигацию, кеш, листинг и т д… Я их называю «самодостаточные контролы» которые могут существовать как в виде отдельного приложения, так и взаимодействуя с другими контроллами.
Во-вторых, для создания простых экспериментов я использую Xamarin, чтоб не было соблазна вмердживать успешные эксперименты в основную ветку. В основной ветке используются нативные инструменты Android и iOS.
Как создать, настроить взаимодействие и поддерживать эти контролы в Nuget — я постараюсь рассказать в своем докладе.
Директор по продукту AMMA Pregnancy.
Отвечаю за стратегическое развитие и вывод продукта на глобальные рынки
Круглый стол. Польза и вред прототипирования
Спикеры: Станислав Продан, Михаил Копытин, Максим Аршинов, Кирилл Маурин
Описание
По мотивам доклада Станислава поговорим о том, в каких случаях целесообразно использовать прототипирование, что потом делать с быстронаписанным кодом, и поделимся личным опытом создания, использования и утилизации прототипов.
О спикерах
Станислав Продан - директор по продукту AMMA Pregnancy.
Михаил Копытин - разработчик с многолетним опытом на .NET. недавно поработал с прототипами, сейчас в составе команды разрабатываю MVP.
Максим Аршинов — спикер dotnext, ndc, ведущий шоу "Барная стойка".
Кирилл Маурин — разработчик с опытом рефакторинга древнего легаси, внедрения полезных шаблонов, технологий и практик в кровавом энтерпрайзе.
Дополнительную информацию о встречах MskDotNet Community Вы можете найти в группах сообщества:
VK https://vk.com/mskdotnet
FB https://www.facebook.com/mskdotnet/
Twitter https://twitter.com/mskdotnet
Telegram https://t.me/mskdotnet
Подписывайтесь на новости, задавайте вопросы, участвуйте в жизни сообщества!