Архитектура фронтенда
Собираем вместе: спроектировать фронтенд
Читать про каскад — не то же самое, что проектировать с ним. Спроектируйте реальное приложение, где каждый слой обязан сосуществовать, и где неверное решение внизу стека всплывёт как симптом, который придётся прослеживать назад. Это капстоун: принять шесть решений, затем доказать каждое через доказательства, а не вкус.
Превратить весь трек в одну связную архитектуру: продуманную модель состояния, слой fetch, защищающий LCP, доступные формы, систему семантических токенов, чистую упаковку в монорепо и code-split сборку — каждое решение обосновано слоем, которому оно принадлежит, и проверено измерением или чеком.
Спроектировать и построить небольшое, но реалистичное многоэкранное фронтенд-приложение (например, дашборд со списком, экраном детали, доступной формой создания/редактирования и тяжёлой вкладкой аналитики), которое принимает защитимое решение на каждом слое трека — state shape, data fetching, forms/a11y, дизайн-токены, упаковка в монорепо и code-split сборка — и доказать, что архитектура держится, метриками и чеками, а не утверждениями.
- Таблица владения состоянием, классифицирующая каждый кусок как server-cache / global / local с однострочным обоснованием, и профиль (React DevTools или эквивалент), показывающий, что ввод в поле поиска ре-рендерит только поддерево поиска, а не весь экран.
- Before/after графа fetch экрана детали — диаграмма waterfall или сетевой трейс — показывающий перекрытие независимых запросов, плюс измеренный LCP меньше 2.5 с на троттлинг-профиле среднего класса.
- Проход по доступности формы: проход только с клавиатуры (порядок tab, фокус на ошибке, escape закрывает), зачитывание скринридером одного пути ошибки и автоматический прогон axe (или эквивалента) с нулём критических нарушений.
- Переключение темы со светлой на тёмную, меняющее только значения токенов — продемонстрировано диффом, показывающим нетронутые файлы компонентов, — и симулированный ребрендинг, меняющий один примитив и каскадирующий повсюду.
- Демонстрация CI: изменение одного пакета собирает/тестирует только затронутые пакеты и берёт остальное из кэша, с графом задач или таймингом до и после работы над границами.
- Отчёт по бандлу (например, анализатор бандлера или Chrome Coverage), доказывающий, что тяжёлая библиотека аналитики отсутствует в начальном чанке и грузится только при открытии вкладки аналитики.
- Добавить упражнение на размещение отказа: намеренно ввести по одному багу на слой (нажатие в глобальном store, независимый fetch за гейтом `enabled`, захардкоженный hex, статический импорт тяжёлого графика) и написать ревью-заметку, прослеживающую каждый симптом к его слою-владельцу.
- Добавить гейт Lighthouse CI, проваливающий сборку, если LCP регрессирует за 2.5 с или начальный бандл вырастает за бюджет, чтобы быстрый путь не мог молча сгнить.
- Добавить a11y-гейт CI (axe в тестовом наборе), проваливающийся на любом новом критическом нарушении в компонентах формы.
- Реализовать рантайм-переключатель тем (светлая/тёмная/высококонтрастная), опирающийся чисто на смену семантического маппинга токенов, и доказать, что третья тема стоит нуля правок в компонентах.
- Добавить remote cache, общий между машинами, и измерить разницу времени CI cold-vs-warm, повторяя результат Mercari о примерно вдвое срезанном времени задач.
Это ревью архитектуры, которое вы будете запускать на каждом реальном фронтенде, проактивно на этапе проектирования вместо реактивного в постмортеме. Принимайте каждое из шести решений осознанно — колокейтить летучее состояние, распараллелить граф fetch, строить доступные формы, слоить токены primitive-to-semantic, рисовать реальные границы пакетов, code-split тяжёлое и редкое — и доказывать каждое доказательством на слое, которому оно принадлежит. Сделав это раз на небольшом приложении, вы доводите каскад стоимости отказа до мышечной памяти, так что на следующем тормозящем дашборде вы тянетесь к state shape, а не к бандлу.