Опубликовано: 29-09-2024

Архитектура программного обеспечения сложна (перевод)

Это перевод статьи на русский (перевод сделан при помощи ChatGPT, поэтому могут быть корявые словосочетания).

Я живу в одном из пригородов Тель-Авива. Однажды утром я проснулся от безумного звука дрели. Началось! Строительство фиолетовой линии легкого метро. «Насколько это будет плохо?» — подумал я...

Спустя несколько недель, просыпаясь в 5 утра в зависимости от начала строительных работ, моя жена сказала, что нам пора съезжать. Пытаясь убедить ее остаться (мне очень нравится этот район!), я попытался найти планы строительства, предполагая, что этап с сильной шумихой не продлится долго.

Когда я ознакомился с планами строительства, как программист, я был поражен. У них были подробные, конкретные планы на три года. Они разделили их на три этапа, с точными измерениями и дорожными структурами для каждого этапа. У них был четкий график. И самое интересное — я легко мог их понять, хотя у меня 0 знаний в гражданской инженерии.

Это, по сути, распространяется и на другие области инженерии и архитектуры. Подумайте о схемах архитектуры здания, электротехники или машиностроения — существуют устойчивые способы записи этих данных, чтобы все другие инженеры в области могли их прочитать. Однако в программной инженерии это не так. Несмотря на то, что легко создать архитектурные диаграммы (используя прямоугольники и стрелки), их чтение и понимание может быть не так просто.

Различия с программной инженерией

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

Эти различия касаются:

Различного уровня абстракции Различного уровня детализации Различных методов иллюстрации/диаграммы Разного акцента на нефункциональных аспектах, таких как надежность, безопасность, конфиденциальность и масштабируемость Такие разрывы в коммуникации часто наблюдаются даже в одной команде, не говоря уже о разных командах, организациях или компаниях. Эти разрывы проявляются, например, в архитектурных диаграммах, которые не являются самоочевидными. Они либо сопровождаются значительным текстовым сопровождением (вспомните 10-страничный проектный документ), либо требуют значительного времени на их объяснение.

Эти разрывы в коммуникации усиливаются из-за недавних тенденций в мире программной инженерии.

Децентрализация роли архитектора

«Архитектура как командный спорт: Архитекторы больше не работают в одиночку, и архитекторы больше не могут думать только о технических вопросах. Роль архитектора значительно варьируется в различных отраслях, и некоторые компании полностью исключили этот титул...»

Отчет о трендах в архитектуре и проектировании ПО от InfoQ — апрель 2023

В прошлом большинство компаний и организаций применяли подход сверху вниз для проектирования и архитектуры программного обеспечения — нанимали архитектора для каждой достаточно большой группы, который выступает в качестве централизованного органа для проектирования продукта/системы. Было обычным делом, что инженеры выполняли задачи по кодированию на основе данной архитектуры, спецификаций и API.

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

По сути, это смена культуры и мышления от процессор проектирования сверху вниз, централизованного, к процессу, который формируется изнутри и «принадлежит всем».

Стоимость

Эти изменения приносят множество преимуществ: усиление и развитие инженеров всех уровней, повышенное чувство собственности и вовлеченности, устранение единой точки отказа и более широкое распространение знаний по командам.

Однако есть и стоимость:

Качество: архитектор обычно квалифицирован как опытный инженер с накоплением опыта в создании и поддержке программных систем. Распределение этой работы среди всех сотрудников команды означает, что никакой дополнительной квалификации, кроме как быть частью команды, не требуется. Чтобы сохранить высокий уровень качества, команды должны вкладывать в обучение, образование и наставничество, строить хороший процесс проектирования и внедрять культуру открытώςtированного fedbackа. Издержки: наличие четкого процесса проектирования в организации помогает повысить планку качества, но вносит значительную нагрузку. Обычно такие процессы включают создание проектного документа, диаграмм системы, блок-схем и включают процесс обратной связи, который может потребовать нескольких итераций и исправлений проекта.

Реализовать здоровый процесс проектирования в организации сложно. Существует напряжение между издержками, которые он вносит, и полученной прибавкой к качеству. Если процесс слишком легкий или его вовсе нет, то и прибавки к качеству нет. Если процесс слишком тяжелый, это может стать обременительным для инженеров, которые могут не полностью следовать ему или даже пытаться его обойти, что в конечном итоге приводит к снижению эффективности. Сладкое место — как всегда нечто среднее.

Существует напряжение между издержками процесса проектирования и достигнутой прибавкой к качеству. Если процесса нет вовсе, то и преимущества никакого. Если процесс слишком тяжелый, инженеры его обойдут, и преимущества уменьшатся. Сладкое место — это что-то посередине.

Практический вывод: Модель C4

О том, каким должен быть здоровый процесс проектирования, можно многое обсудить, но один практический концепт, который я хочу отметить, — это модель C4.

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

Диаграммирование → Моделирование

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

Модель C4 состоит из 4 уровней абстракции (отсюда и название):

1. Контекст системы: самый высокий уровень абстракции. Этот слой содержит внутренние системы, внешние системы, пользователей (если существует несколько типов пользователей, их следует указать) и отношения между ними.

2. Контейнер: когда ваша система определена, вы можете увеличить масштаб и приблизиться к конкретной системе. Система состоит из одного или нескольких контейнеров. Контейнер представляет приложение или хранилище данных, такое как: бекенд-сервис, фронтенд-приложение, мобильное приложение, реляционная БД, key-value хранилище, message bus, объектное хранилище и т. д.

Простым способом думать об этом, по крайней мере с позиции бекенда, является мысль о раздельных процессах/исполняемых модулях. Каждый исполняемый модуль сопоставляется со своим контейнером.

Если вы уже принимали участие в интервью по проектированию системы, обычно это фокусируется на слое контейнера.

3. Компонент: следом, контейнер может быть разбит на несколько компонентов, обычно по функциональности и областям ответственности. Например, если взять бекенд-сервис платежей, он может включать такие компоненты, как: исполнитель платежей, клиент сторонних сервисов, механизм восстановления, записывающий платежи, отправитель уведомлений и т. д.

Это нормально, если компоненты контейнера взаимодействуют с другими контейнерами из уровня 2 — например, механизм восстановления может отправить сообщение в message bus для повторной попытки завершения неудавшегося платежа через определенную задержку.

4. Код: это сопоставление компонентов с фактическими кодами классов/модулей и т. д. Этот слой деталей обычно менее интересен и очень трудно поддерживать и в большинстве случаев не рекомендуется.

Тем не менее, при написании кода может быть полезно думать: «В какой компонент входит мой код?». Если ответ не ясен, либо вы создаете новый компонент, либо нарушаете существующие границы компонентов.

Несколько примечаний к модели C4:

Критические слои — Контейнер и Компонент. Важны ваши проектные решения на уровне Контейнера, так как они влияют на масштабируемость, надежность, развертывание и возможность развития проекта. Ваши проектные решения на уровне Компонента влияют на скорость разработки, эффективность, поддерживаемость и качество.
Модель C4 добавляет глубину архитектурным диаграммам программного обеспечения. Думайте о ней как об онлайн-карте — вы начинаете с высокоуровневого обзора и можете увеличивать масштаб в интересующих вас местах. Если вы забрались слишком далеко в детали, вы можете отдалить изображение обратно и оказаться в охватывающей архитектуре.
Модель C4 является долгосрочной, совместной моделью. Вместо того, чтобы каждый инженер создавал свою случайную диаграмму, модель C4 может быть разделена и отредактирована несколькими инженерами или командами, расширяясь по мере роста организации и продукта.
Существует множество инструментов, поддерживающих модель C4. В наше время даже распространенные корпоративные программы для создания диаграмм имеют шаблон C4.

Заключение

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

С недавними тенденциями в децентрализации роли архитектора и поддержкой «архитектуры как командного спорта» структура команд по разработке программного обеспечения меняется, и организациям необходимо тщательно обдумать, как будет выглядеть их процесс проектирования, и найти правильный баланс между введением дополнительных издержек для поддержания высокого качества.

Еще один интересный вопрос — как долгосрочно разрабатывать и проектировать программное обеспечение под влиянием генеративного ИИ. Мы уже видим изменения в повседневной работе инженеров с использованием AI-инструментов, ко-пилотов и агентов.

Как выглядит процесс проектирования в вашей организации? Видите ли вы его структурированным и имеющим ощутимое значение? Или есть области для улучшения? Будет интереснο услышать ваши мысли в комментариях ниже.