Перейти к основному содержимому

Frontend-архитектура

Для чего модуль​

Научиться проектировать frontend-архитектуру, которая выдерживает рост продукта, команды и требований к качеству.

Результат после прохождения​

  1. Вы умеете строить модульные границы и управлять зависимостями.
  2. Вы снижаете архитектурный риск через ownership и правила взаимодействия модулей.
  3. Вы можете эволюционировать legacy-зоны без остановки разработки.
  4. Вы защищаете архитектурные решения через метрики и эксплуатационные последствия.

Термины и аббревиатуры​

ТерминКоротко
CouplingСвязанность модулей
CohesionЦелостность модуля
OwnershipОтветственный за зону
Dependency mapКарта зависимостей
Migration planПлан перехода

Фокус по грейдам​

  1. Junior: понимать базовые механики и объяснять их простыми примерами.
  2. Middle: применять тему в продуктовых сценариях с учетом рисков и ограничений.
  3. Senior: управлять архитектурными trade-offs, метриками и эволюцией решения.

Как работать с модулем​

  1. Возьмите один проблемный участок текущего frontend-кода.
  2. На каждом уроке фиксируйте: текущая проблема -> целевая архитектура -> план перехода.
  3. После каждого урока обновляйте dependency map и ADR.

Программа модуля​

Урок 1. Модульность и слои​

Цель: разделить систему на зоны ответственности с минимальной связанностью.

Базовые архитектурные слои​

  1. UI/presentation.
  2. Domain/use-cases.
  3. Data/integration.
  4. Shared/platform.

Принципы модульности​

  1. Высокая cohesion внутри модуля.
  2. Низкая coupling между модулями.
  3. Явные public API модуля, скрытые внутренности.

Где ломается в проде​

  1. Shared слой превращается в «свалку» зависимостей.
  2. Модули импортируют внутренности друг друга.
  3. Нет правил направления зависимостей.

Мини-задача (обязательная)​

Сделайте dependency map одного крупного флоу и выделите 3 нарушения модульных границ с планом исправления.

Что спросит интервьюер: как понять, что модульная архитектура «работает», а не только красиво нарисована.

Критерий готовности по уроку: вы можете показать архитектурную карту системы и объяснить, где сейчас риск связанности.

Урок 2. Ownership и процессы​

Цель: привязать архитектуру к ответственности команды.

Ownership model​

  1. У каждого модуля есть владелец.
  2. Ясные правила изменений cross-module.
  3. SLA реакции на инциденты и архитектурные регрессии.

Архитектурные quality gates​

  1. PR-check для границ модулей.
  2. ADR для значимых изменений.
  3. Автоматические проверки зависимостей (где возможно).

Где ломается в проде​

  1. «Общий код» без владельца.
  2. Критичные решения принимаются устно и не документируются.
  3. Инциденты повторяются, потому что ownership не определен.

Мини-задача (обязательная)​

Опишите ownership-matrix для 5 ключевых модулей: owner, reviewer, SLA, эскалация.

Что спросит интервьюер: как вы распределяете ответственность за архитектурные зоны.

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

Урок 3. Архитектурная эволюция​

Цель: менять архитектуру постепенно и безопасно.

Подход к миграции​

  1. Выделяем наиболее рискованную зону.
  2. Планируем этапы с checkpoints.
  3. Оставляем rollback-вариант на каждом этапе.

Измерение прогресса​

  1. Снижение cross-module связей.
  2. Снижение числа архитектурных нарушений.
  3. Влияние на delivery (lead time, defect rate).

Где ломается в проде​

  1. Попытка «переписать всё» вместо локальных шагов.
  2. Нет критериев завершения этапа.
  3. Команда теряет скорость из-за неограниченного scope миграции.

Мини-задача (обязательная)​

Составьте план архитектурной эволюции на 6 недель для одного legacy-модуля: этапы, риски, метрики, rollback.

Что спросит интервьюер: как вы эволюционируете архитектуру без остановки бизнес-фич.

Критерий готовности по уроку: вы можете показать реалистичный план изменений с управлением риском и влиянием на delivery.

Урок 4. Практика принятия решений​

Цель: выстраивать архитектурный диалог на языке компромиссов и последствий.

Decision record​

Для каждого решения фиксируйте:

  1. Контекст и проблему.
  2. Альтернативы.
  3. Выбор и rationale.
  4. Риски и mitigation.
  5. Метрики проверки.

Работа с возражениями​

  1. «Слишком сложно» -> показываем cost of current complexity.
  2. «Долго» -> этапность и quick wins.
  3. «Можно потом» -> риск накопления техдолга и стоимость откладывания.

Мини-задача (обязательная)​

Подготовьте мини-ADR на одно спорное решение и проведите архитектурную защиту (3 ожидаемых возражения + ответы).

Что спросит интервьюер: как вы защищаете архитектурный выбор, если команда не согласна.

Критерий готовности по уроку: вы ведете архитектурную дискуссию структурно и предметно, без «религиозных» аргументов.

Практика​

  1. Постройте dependency map и register архитектурных нарушений.
  2. Подготовьте ownership-matrix для ключевых модулей.
  3. Оформите 1-2 ADR на значимые решения.
  4. Сделайте 6-недельный migration plan для проблемной зоны.
  5. Закрепите в Senior Frontend и Playbook.
  6. Соберите dependency map проблемной зоны в Песочнице и проверьте план упрощения.

Связь с треками и вопросами​

  1. Треки: Middle трек, Senior трек.
  2. Вопросы: Senior Frontend, Playbook.
  3. Повторение: 3-5 вопросов без подсказок -> сверка с модулем -> повтор через 24 часа.

Критерий готовности​

Вы обосновываете архитектуру через продуктовые ограничения, риски и измеримое влияние на delivery.

Артефакты после модуля​

  1. Dependency map + violation register.
  2. Ownership-matrix.
  3. ADR-пакет по ключевым решениям.
  4. План эволюции проблемного модуля.

Куда дальше​

  1. Frontend System Design
  2. Тестирование frontend
  3. Frontend-архитектура