Архитектура фронтенда
Собираем вместе: тест с выбором ответа
Каждый вопрос здесь пересекает два-три юнита. Капстоун проверяет не запоминание одного слоя, а навык: прочитать симптом и назвать самый нижний слой, которому он принадлежит, — именно там живёт устойчивый фикс.
Убедиться, что вы умеете проследить симптом фронтенда вниз по каскаду — state shape, граф fetch, токены, границы монорепо, splitting, pipeline — и отвергать фиксы, которые оптимизируют слой выше реальной причины.
Дашборд тормозит на каждом нажатии клавиши в поле поиска. Коллега заводит тикет: применить code-splitting и лениво грузить графики. Как читает это senior?
Страница товара рисует скелетон, затем гидрируется JS, затем фетчит пользователя, потом корзину, потом рекомендации — каждый ждёт предыдущего. LCP — 4.8 с. Какому слою это принадлежит и в чём фикс?
Маркетинг просит ребрендинг: новый брендовый цвет плюс тёмную тему. В кодовой базе брендовый hex захардкожен в ~300 компонентах. Что это вскрывает и в чём структурный фикс?
CI занимает 15 минут на однострочное изменение в одном из 12 пакетов, потому что всё импортирует один гигантский shared-пакет. Что бьёт по корневой причине?
Вам дали новый фронтенд на ревью. В каком порядке senior оценивает слои и почему именно так?
Тяжёлая библиотека графиков грузится на первой отрисовке каждого маршрута, хотя большинство пользователей никогда не открывают вкладку аналитики, а пользователь скринридера сообщает, что date-picker внутри неё ловит фокус в ловушку. Какой двухслойный фикс верен?
Сквозная линия трека — это одно дерево решений. Где живёт состояние, задаёт радиус поражения ре-рендера; граф fetch владеет LCP; токены решают, будет ли ребрендинг сменой значения или охотой по файлам; границы монорепо — это множитель времени сборки; splitting и pipeline — самые дешёвые слои. Каждый вопрос выше — это один и тот же ход: прочитать симптом, спуститься к самому нижнему слою, которому он принадлежит, и отвергнуть любой фикс, оптимизирующий слой выше причины.