«Всем придётся стать архитекторами». Главные выводы и прогнозы по Software Architecture с митапа TechSpot

Кто пишет: Антон Васильев, CTO компании On The Spot — организатора митапов TechSpot про IT-архитектуру и распределенные системы. 
Обязательно прочитайте, как On The Spot организовывали митапы в Варшаве. 

«Ценность  системы — это ее связи, а не сумма компонентов»

Спикер: Влад Хононов, Software Architect, автор «Learning Domain-Driven Design» издательства O’Reilly и известный спикер. Доклад ссылался на новую книгу Влада «Balancing Coupling in Software Design», которая еще не опубликована.

• Термин «coupling» (связанность) определяет, насколько взаимозависимы компоненты в системе. Обычно рекомендуют стремиться к низкому количеству связей, так как каждая из них уменьшает степень свободы. Однако Влад Хононов предлагает взглянуть на ценность системы не как на сумму частей, а оценивать сами связи.
• Связанность — не препятствие, а инструмент проектирования: она помогает выявить изменения, которые можно внести в систему, сохраняя при этом ее функциональную целостность. 
• Вместо того, чтобы избавляться от связанности, оцените связи в системе: работают они на вас, против вас, и можно ли обратить их в свою пользу. «Хорошая» связанность или нет, зависит от сочетания параметров Сила, Расстояние и Изменчивость.
• Сила — это то, насколько влияют изменения в одном компоненте на другие. Чем больше Расстояние между связанными компонентами, тем сложнее координировать реализацию изменений. Поэтому цена изменений пропорциональна расстоянию между компонентами, а жизненный цикл ему обратно пропорционален. Изменчивость — это частота модификации связанных компонентов. Если компания предлагает инновации и выделяется на рынке, Изменчивость будет высокой.
• Чем выше Сила, тем выше вероятность каскадных изменений. Чем выше Изменчивость, более нестабильна система и тем чаще придется заботиться об изменениях. Чем выше Расстояние, тем сложнее координация и выше цена изменений.
• Оценивая параметры выше, можно узнать «стоимость» связанности — или же, по термину Влада, «Боль от обслуживания». Боль от обслуживания = Сила * Расстояние * Изменчивость. 
  Соответственно, чтобы минимизировать Боль от обслуживания системы, нужно один из параметров сделать = 0. Оценивая возможности этого, можно принимать прагматичные решения по развитию системы.

А вот и запись доклада: 

«Разработка сложных систем изменилась»

Спикер: Иван Подобед, Director Platform Architecture в PandaDoc. 

В докладе «The Next Big Thing In Architecture Domain» Иван поведал о трансформации архитектурных практик, сделал прогнозы и представил свой стартап. 

• Процесс разработки сложных систем изменился. Принятие решений становится распределенным потоком, который затрагивает проектирование продукта и организации.
  
  Схема из книги «Facilitating Software Architecture» .
• Техлиды, архитекторы или другая централизованная власть становится узким местом в динамичных компаниях. Есть два решения: поставить архитектора в каждую команду или сделать всю команду «архитектором», то есть наращивать потенциал принятия архитектурных решений. Все, кто имеет полномочия и потребность влиять на продукт, являются архитектором.
• Настоящий кросс-функциональный подход — это про междисциплинарность,  а не про добавление в одну команду бэкенда, фронтенда и QA. 
• Решения РМов, сейлзов, аналитиков влияют на дизайн и эволюцию системы, но не имеют ни ADR, ни архитектурной документации. Значительная часть контекста, важного для создания успешной архитектуры, остается не документирована.
• Fitness function помогает определить, хороша ли архитектура, но не дает нам достаточного понимания системы. Приведение к наименьшим значениям — хорошо, но можно ли построить из них масштабную систему?
• Эволюция — это последовательные изменения системы в рамках отдельной продуктовой области-домена, которая развивается к идеальному состоянию. А фитнес-функция только позволит механически проверить качество отдельных аспектов системы (пуговицы пришиты хорошо, но пиджак все равно не застегивается — пуговицы сделаны из бумаги).
• Единственная действенная логическая декомпозиция системы — на основе домена (см. DDD), потому что она гарантирует согласованность coupling и cohesion.
• Архитекторы тоже ошибаются. Поэтому сотрудничество и помощь команды, особенно если она разделяет контекст, важны. Но нужен продвинутый тулинг.
• Сотрудничество, а также оунершип полного цикла (концепт «You Build It, You Run It») — две большие тенденции будущего.
• Действительно сильные команды способны нести ответственность за свои решения, их последствия и могут напрямую общаться с кастомерами. Быть product-minded инженером — это уметь строить причинно-следственные связи насчет проектирования, эксплуатации и внедрения системы.
• В будущем инженерные команды должны стать архитекторами. То есть расширить области экспертизы, уровень ответственности и видеть систему на более глубоком уровне. 
• Самое главное: всем придется стать архитекторами. И инженерам, и продуктовым менеджерам, и инженерным менеджерам, и аналитикам. Сделать так, чтобы все стали архитекторами, очень непросто. Нужна будет помощь инструментов нового поколения, которые умеют работать с полным контекстом систем. Одним из таких инструментов станет System5.dev — новый продукт, который представил Иван. На сайте уже можно попробовать и применить новый Architecture Copilot.

А вот и запись доклада: 

А что вы думаете по поводу этих пунктов? Срезонировало ли что-то с вашей практикой? Поделитесь мнением, можем обсудить в комментариях. 

Мнение автора может не отражать позицию редакции. 

dev.by, как и другим честным медиа, сегодня очень сложно: редакция работает за пределами страны, а наши рекламные доходы сократились в несколько раз. Но мы справляемся — с вашей помощью. Это вы делитесь с нами инфоповодами, мнениями, опытом, временем и вниманием. А 230 читателей поддерживают нас донатами.

В 2023 году мы хотим собрать 1000 читателей-подписчиков.

Помочь нам можно через Patreon. 
Из Беларуси — через Donorbox.
И ещё криптой, тут кошельки.

Спасибо, что прочитали это сообщение.

Что ещё почитать у комьюнити: 

• Tech lead с 20+ годами опыта рассказывает, как проводит собесы; 
• «Какой бэкграунд у фаундеров?» и ещё 17 вопросов, которые стоит задать на собеседовании в стартап;
• Как PM найти работу в Европе? Рассказывает та, которой удалось;