Начнем с развенчания мифа. Архитектура не обязательно означает большой предварительный дизайн
Вероятно, это было правдой во времена водопада, но не сейчас.
Крупные проекты заранее или вообще никаких дизайнов. Это две крайности в спектре. Первый тупой, а второй, вероятно, еще тупее. Мы должны начать с достаточного архитектурного дизайна. Как узнать, сколько достаточно?
Как и большинство вещей, это зависит от варианта использования. Это зависит от того, предназначено ли приложение, которое вы создаете, для
- Большое предприятие
- Стартап с новым продуктом
- Или что-то посередине
Еще один важный момент - дизайн должен быть живым и развивающимся.
- Создание статического (мертвого) архитектурного документа, на который никто больше не ссылается, бесполезно.
- Дизайн должен отражать текущее состояние приложения и развиваться вместе с меняющимися требованиями.
Архитектура представляет собой важные решения, значимость которых измеряется стоимостью изменений - Грэди Буч
- Вначале сосредоточьтесь на таких важных вещах, как язык программирования, платформы. Выбор между монолитом, микросервисами или модульными монолитами.
- Менее значимые проблемы, такие как табуляции или пробелы, позиции скобок и т. Д., Могут быть решены позже.
Подтвердите свою архитектуру конкретными экспериментами.
- Протестируйте архитектуру с реальным кодом
- Выявление и снижение рисков наивысшего приоритета (RUP)
Архитектура предназначена не только для крупномасштабных систем, таких как система управления Международной космической станции. У каждого приложения есть архитектура, независимо от того, хорошо ли она спроектирована и продумана.
Опасности непроектирования архитектуры.
- Хаос в команде, а также в кодовой базе
- Большой шар компонентов грязи
- Код спагетти
Роль архитектора - кодирование, коучинг и сотрудничество.
- Не быть Aaas - (Архитектура как услуга). Создание архитектуры должно быть совместным, а не директивным процессом.
- Это постоянная роль, когда вы прекращаете проектировать архитектуру, она начинает проектировать сама.
- Парные архитекторы - как парные программисты
- Мягкие навыки
- Архитекторы должны писать производственный код. Лучше держать руку на пульсе кодовой базы.
Документация по архитектуре
UML не нужен. Все равно никому это не нравится. Тогда что нам использовать? Доски?
- Вездесущий язык
- Модель C4 Link
- Контекст, контейнеры, компоненты и код
- Разные диаграммы на разных уровнях абстракции
- Схема как ссылка на код, Structurizr
Архитектура обеспечивает гибкость
- Мы все были там. Начинали из лучших побуждений, но где-то по ходу код превратился в большой ком грязи.
- Хорошо структурированные и высокомодульные приложения легко изменять и управлять ими.
Эта статья основана на выступлении Саймона Брауна.
Недавняя книга Саймона Архитектура программного обеспечения для разработчиков
Первоначально опубликовано на https://www.hashjar.dev.