Архитектура фронтенда
Собираем вместе: тест на свободное припоминание
Припоминание побеждает перечитывание. Каждый промпт охватывает сразу несколько юнитов — ответьте на него полностью по памяти, прежде чем открывать модельный ответ, потому что восстановление связи между слоями — ровно тот senior-навык, который проверяет этот капстоун.
Восстановить весь трек как один каскад — почему state shape лежит в основании, как граф fetch владеет LCP, что даёт семантический слой токенов, почему границы — множитель времени сборки и как ревьюить всё это в порядке стоимости отказа.
- 01Почему senior ревьюит фронтенд снизу вверх по стоимости отказа, а не сверху вниз по структуре файлов, и какие слои самые дорогие против самых дешёвых в ошибке?
- 02Дашборд тормозит на каждом нажатии, команда хочет применить code-splitting к графикам. Пройдите путь поиска реального слоя и почему их фикс провалится.
- 03Как слой data fetching решает LCP и что превращает медленную страницу в быструю?
- 04Объясните трёхслойную структуру токенов и что даёт каждый слой, когда прилетает ребрендинг или тёмная тема.
- 05Почему границы монорепо — это множитель времени сборки и какие два рычага сильнее всего режут время CI?
- 06Когда code-splitting — правильный инструмент, а когда неправильный, и как splitting и build pipeline связаны со слоями ниже них?
Если вы смогли восстановить каждый ответ по памяти, у вас в руках хребет трека: state shape задаёт радиус поражения ре-рендера, граф fetch владеет LCP, слой токенов primitive-to-semantic делает ребрендинг сменой значения, чистые границы монорепо плюс affected-only выполнение и remote cache — множитель времени сборки, а code splitting и pipeline — самые дешёвые слои, чинимые последними. Повторяющийся ход — прочитать симптом, спуститься к самому нижнему слою, которому он принадлежит, и чинить там — никогда не патч на слой выше причины.