Это перевод статьи на русский (перевод сделан при помощи 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-инструментов, ко-пилотов и агентов.
Как выглядит процесс проектирования в вашей организации? Видите ли вы его структурированным и имеющим ощутимое значение? Или есть области для улучшения? Будет интереснο услышать ваши мысли в комментариях ниже.