Начнем с развенчания мифа. Архитектура не обязательно означает большой предварительный дизайн

Вероятно, это было правдой во времена водопада, но не сейчас.

Крупные проекты заранее или вообще никаких дизайнов. Это две крайности в спектре. Первый тупой, а второй, вероятно, еще тупее. Мы должны начать с достаточного архитектурного дизайна. Как узнать, сколько достаточно?

Как и большинство вещей, это зависит от варианта использования. Это зависит от того, предназначено ли приложение, которое вы создаете, для

  • Большое предприятие
  • Стартап с новым продуктом
  • Или что-то посередине

Еще один важный момент - дизайн должен быть живым и развивающимся.

  • Создание статического (мертвого) архитектурного документа, на который никто больше не ссылается, бесполезно.
  • Дизайн должен отражать текущее состояние приложения и развиваться вместе с меняющимися требованиями.

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

  • Вначале сосредоточьтесь на таких важных вещах, как язык программирования, платформы. Выбор между монолитом, микросервисами или модульными монолитами.
  • Менее значимые проблемы, такие как табуляции или пробелы, позиции скобок и т. Д., Могут быть решены позже.

Подтвердите свою архитектуру конкретными экспериментами.

  • Протестируйте архитектуру с реальным кодом
  • Выявление и снижение рисков наивысшего приоритета (RUP)

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

Опасности непроектирования архитектуры.

  • Хаос в команде, а также в кодовой базе
  • Большой шар компонентов грязи
  • Код спагетти

Роль архитектора - кодирование, коучинг и сотрудничество.

  • Не быть Aaas - (Архитектура как услуга). Создание архитектуры должно быть совместным, а не директивным процессом.
  • Это постоянная роль, когда вы прекращаете проектировать архитектуру, она начинает проектировать сама.
  • Парные архитекторы - как парные программисты
  • Мягкие навыки
  • Архитекторы должны писать производственный код. Лучше держать руку на пульсе кодовой базы.

Документация по архитектуре

UML не нужен. Все равно никому это не нравится. Тогда что нам использовать? Доски?

  • Вездесущий язык
  • Модель C4 Link
  • Контекст, контейнеры, компоненты и код
  • Разные диаграммы на разных уровнях абстракции
  • Схема как ссылка на код, Structurizr

Архитектура обеспечивает гибкость

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

Эта статья основана на выступлении Саймона Брауна.

Источник: GOTO 2020 * Пять вещей, которые каждый разработчик должен знать об архитектуре программного обеспечения * Саймон Браун

Недавняя книга Саймона Архитектура программного обеспечения для разработчиков

Первоначально опубликовано на https://www.hashjar.dev.