Архитектура

При занятии разработкой приложений с общей архитектурой, но отличающихся по содержанию, возникает проблема эффективного переиспользования общих компонентов в разных проектах и командах.

В моем докладе я поделюсь нашим опытом разработки транспортных продуктов в компании Островок, объяснив причины выбора Git-сабмодулей вместо монорепозитория и описав способы переиспользования общих компонентов и модулей транспортных продуктов в различных проектах и командах.

Также мы рассмотрим технические детали работы с Git-сабмодулями, их плюсы и минусы, и проведем сравнение данного подхода с альтернативными методами.

В докладе будет представлено краткое описание методологии ADD (Attribute Driven Design), даны основные определения, схема и принцип работы по данной методологии, а также приведена оценка полезности применяемого подхода на этапе проектирования архитектуры сложных, высоконагруженных проектов.

Основной упор будет сделан на практическое применении данной методологии на примере проектов, реализуемых компанией SimbirSoft. В рамках доклада я планирую рассказать каким образом осуществляется приоритизация требований по шкале (H, M, L), как правильно составлять таблицы ASR (Architecturally Significant Requirements), выбирать различные паттерны и оценивать их применимость, определять обязанности и интерфейсы, проверять что все требования учтены. Все перечисленные шаги будут подкреплены примерами.

Также будут затронуты вопросы автоматизации процесса проектирования и подготовки архитектурного каркаса на основе подхода Design API First в рамках методологии ADD, автоматической генерации кода и документации, а также повторного использования готовых решений.

Также планирую рассказать как мы встраиваем методологию ADD в наш проектный конвейер на примере реализации процесса аутентификации пользователей и как подобного рода решения можно эффективно использовать повторно в других проектах. В конце поделюсь примерами готовых документов, которые можно использовать как шаблоны при разработке Архитектурных концепций по методологии ADD

Мы разберем типовое web приложение со стороны backend на компоненты, определим категорию и зону ответственности этих компонентов и посмотрим на их составные части. Основой архитектуры будет использование паттерна Clean Arch, который хорошо себя зарекомендовал. Мы будем предполагать, что работа по выделению доменных областей проведена, стек технологий и сервисы для интеграции выбраны. Если посмотреть на уровни моделью декомпозиции [С4](https://c4model.com/), мы будем проектировать 3 уровень - диаграмму компонентов приложения.

Операционные системы нам кажутся уже устоявшимся миром, но это не так. Требования надежности и безопасности постоянно повышаются, и старые ОС такие как macOS, Windows и Linux здесь безсильны. На сцену выходят ОС на основе микроядра: безопасная операционка KasperskyOS от Лаборатории Касрерского, идущая на смену Андроида Fuchsia от Google и ветеран seL4. Но что такое микроядро и как оно устроено?

Давайте разберем что такое ОС в целом, как работают “монолитные” и новые микро-ядра. Что такое модель MILS. Заглянем под капот и разберемся с базовыми блоками на которых строятся современные микроядра. Разберем на пальцах такие основополагающие механизмы как: capability, message passing и конечно же что делает KasperskyOS более защищенной ОС.

Доклад о применение идеи String API для разделения программы на независимые модули.

Как построить гибкую программую систему независимых компонентов. Распределение данных и реакция на события.

- Почему важна фиксация ключевых архитектурных решений

- Инструмент ADR как способ фиксации ключевых архитектурных решений, и как он связан с другими артефактами проекта (описанием архитектуры, постановкой задач и т.д.)

- Как ADR можно реализовать и использовать в разных типах проектов

Аудитория вебинара - аналитики, разработчики и специалисты по инфраструктуре, занимающиеся проектированием решений в проекте. Руководители проекта, не проходите мимо - это и вас касается

На вопрос декомпозиции системы (решения, продукта) на блоки, модули, компоненты, сервисы и микросервисы приходится отвечать большинству команд.

Техника Event Storming, направленная на быстрое командное изучение предметной области, позволяет найти ответ и на вопрос декомпозиции решения.

Как - расскажу в докладе и проиллюстрирую примером.

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

- надо ли нам думать о надежности нашей системы и от чего это зависит

- как оценить надежность существующей системы

- почему надежность сложно добавить в существующую систему

- какие существуют принципы для проектирования надежных систем

- как выстроить процессы для ее достижения

Современные методы разработки ПО предполагают непрерывное ускорение процессов разработки, а области автоматизации постоянно усложняются. Какие вызовы это создаёт в работе архитектора и какими инструментами уже имеющимися или будущими можно с ними бороться?

Когда программа стабильно работает, линтеры не находят багов, код всё равно может слабо поддерживаться и трудно масштабироваться. Часто проблема связана с неэффективным неймингом.

Поговорим о том, как добиться чистого кода и внедрить непротиворечивые практики нейминга в разработке.

Внутри доклада подсветим вопросы:

1. Половина времени код-ревью уходит на разъяснения и комментарии, касающиеся названий сущностей в коде. То, как будут поименованы объекты, переменные, влияет не только на сам процесс ревью, но и на предсказуемость работы ПО при развитии и масштабировании. Даже если программа работает, но читаемость её кода на низком уровне, со временем такой код приходится переписывать из-за сложной поддержки.

2. Чистый код равно литературный код. Требования к написанию кода сильно изменились. Если раньше программисту было важно разбираться в том, как устроено “железо”, то сегодня во главе угла — умение чётко формулировать: насколько точно разработчик умеет выражать свои мысли, насколько код легко читать и воспринимать.

3. Самодокументируемый код. В идеальном мире хорошему коду не требуется документация. Соблюдение унифицированных и общих правил для выбора названий переменных, коммитов и мёрдж-реквестов позволяет писать код и ориентироваться в нём быстрее.

Практика:

— основные ошибки и проблемные моменты, которые часто встречаются на ревью.

— список рекомендаций по неймингу: подбор терминов (с примерами), внедрение политик по единообразному неймингу в компании и др.