📖 Навигация и запрос

Браузер получает URL и дальше по цепочке: DNS → TCP → TLS → HTTP. Если здесь всё больно — никакой React, Next и прочие заклинания уже не помогут.

Парсинг HTML
HTML читается сверху вниз и превращается в DOM. На пути встретился <script> без defer или async — парсинг встаёт на паузу. Браузер честно ждёт, пока скрипт выполнится, даже если тот вообще не про первый экран.

Парсинг CSS
CSS превращается в CSSOM. Без него браузер не может рендерить — он просто не знает, как должна выглядеть страница.

DOM + CSSOM = render tree.
До этого момента экран пустой.

Layout (reflow)
Теперь браузер считает размеры и позиции элементов. width: auto, flex, grid, проценты — всё это вычисляется именно здесь. Это один из самых дорогих этапов во всей цепочке.

Paint
Элементы рисуются по слоям: текст, фоны, бордеры, тени. Пока ещё не на экране — всё это складывается в буфер.

Composite
Слои собираются вместе, применяются transform, opacity. И только теперь кадр наконец уходит на экран. Вот он, первый paint.

✈️ JavaScript включается в игру

После первого paint начинается самое весёлое:
— hydration
— эффекты
— подписки
— измерения (getBoundingClientRect, привет)

И тут часто вылезают:
— layout thrashing
— CLS
— лишние перерендеры

⏲ Почему «быстрый сервер» ≠ быстрый рендер

— большой CSS блокирует рендер
— JS без defer стопорит DOM
— шрифты двигают layout
— аналитика ломает первый кадр

Сервер может быть молниеносным, а страница всё равно ощущаться медленной. Чем меньше браузер думает до первого paint, тем быстрее страница кажется пользователю.

1. Создаем новый чат;
2. Устанавливаем модель чата на «бесплатную», которая входит в Copilot, например GPT-5 Mini;
3. Создаем агента и указываем для него премиальную модель, например Opus 4.5;
4. Переключаемся в режим работы «Агент»;
5. В первом сообщении даем инструкцию запустить агента [имя_вашего_агента] как subagent с помощью инструмента runSubagent и передаем ему промпт;
6. Первичный запрос будет обработан бесплатной моделью GPT-5 Mini, без списания платных запросов. Бесплатная модель создаст subagent. Ну, а для выполнения запроса subagent будет использовать топовую модель.

🙂 Layered архитектура: за что её любят

Классический расклад:

/ui
/services
/api
/store
/utils

Почему она всем так знакома:
— понятна с первого дня
— легко стартовать проект
— хорошо ложится на обучение и онбординг

Но дальше начинается рост. И вместе с ним — боль.

Где начинает тянуть:
— бизнес-логика размазывается по слоям
— одна фича требует правок в 5 папках
— utils постепенно превращается в свалку
— удалить фичу целиком почти невозможно

Layered отлично работает, пока проект небольшой или команда держит жёсткую дисциплину.

➕ Feature-based архитектура: за что её выбирают

Структура по смыслу, а не по типам:

/features/cart
/features/auth
/features/profile

Внутри фичи — всё своё:
— UI
— логика
— запросы
— типы

Что это даёт:
— высокая связность
— фича живёт в одном месте
— проще удалять и рефакторить
— легче масштабировать команду

Но бесплатно тут тоже ничего нет.

Где начинаются подводные камни:
— риск дублирования
— нужны чёткие границы между фичами
— без соглашений хаос наступает очень быстро

🔫 Где на самом деле правда

Layered — это удобство старта. Feature-based — это удобство жизни проекта.

Поэтому на практике почти всегда побеждает гибрид:
— core / shared — слоями
— бизнес-фичи — по фичам
— UI-кит отдельно
— доменная логика не размазывается по проекту

❌ Главная ошибка

Выбирать архитектуру как религию. Не задавая простых вопросов:
— сколько людей будет в проекте?
— как часто добавляются и удаляются фичи?
— важнее быстрый старт или долгоживущая поддержка?

❗️ Когда нет проблемы

Самый частый сценарий. Код работает, покрыт тестами, понятен команде, но кому-то просто «не нравится стиль».

Что получается в итоге:
— переписаны десятки файлов
— история изменений размазана
— баги появляются из ниоткуда

Рефакторинг ради эстетики — это не инвестиция, а хобби.

💬 «Давайте быстренько подчистим архитектуру» — худшая мысль за неделю до дедлайна

Почему это опасно:
— резко растёт риск регрессий
— тесты не ловят всё
— команда теряет фокус на бизнес-цели

Перед релизом рефакторят только то, что действительно блокирует выпуск.

🔎 Без чёткой цели

Фразы-триггеры, которые должны настораживать:
— «давай просто улучшим»
— «тут можно сделать красивее»
— «я бы переписал по-другому»

Хороший рефакторинг всегда отвечает на вопрос: какую конкретную боль он снимает? Плохой — не отвечает ни на один.

👥 Когда команда не готова

Рефакторинг быстро превращается в «личный стиль автора». Через месяц никто уже не понимает, почему код выглядит именно так.

Если:
— нет общих соглашений
— нет документации
— нет нормального код-ревью

⬆️ Когда рефакторинг подменяет развитие

Иногда рефакторинг — это способ не делать фичи. Потому что:
— страшно трогать бизнес-логику
— нет ясных требований
— хочется заняться «безопасной» работой

Но пользователю всё равно, насколько у вас элегантный код.

📣 Как понять, что рефакторинг оправдан, во всех остальных случаях — осторожно

Он действительно нужен, если:
— код мешает добавлять фичи
— правки регулярно ломают соседние части
— баги повторяются в одном месте
— время изменений стабильно растёт

✈️ Почему utils деградирует быстрее всего

«Вдруг кому-то ещё пригодится»: Код попадает в shared не потому, что он реально общий, а потому что «может быть когда-нибудь».

Отсутствие владельца: Ничей код = любой код. В итоге никто не отвечает ни за качество, ни за границы.

Смешение уровней. Это уже не utils, а архитектурная свалка. В одной папке оказываются:
— чистые функции
— бизнес-логика
— куски UI
— знания про стор и API

👏 Главное правило

Shared — это не место.
Shared — это контракт.

Код может туда попасть только если:
— используется минимум в двух фичах
— не знает ничего о бизнес-контексте
— не зависит от стора, API и UI
— стабилен по своему API

Если функция знает про User, Order или Cart — это уже не shared.

💡 Что делать вместо utils.ts

Дробить по смыслу

shared/date
shared/number
shared/string
shared/collection

Выносить домен в фичи: formatPrice для корзины живёт в features/cart, а не в shared.

Делать явные адаптеры: Если код связывает два мира — это уже не утилита, а адаптер или сервис.

Красные флаги
— файл на 500+ строк
— функции без тестов
— названия с helper, common, misc
— зависимость от окружения (window, store, env)

📣 Практики, которые реально спасают

— Запрет прямых импортов из shared/utils/*
— Индексные экспорты с явным API
— Ревью с вопросом: «почему это shared?»

❗️ Типы проверяют форму, а не смысл

type User = {
id: string
role: string
}

С точки зрения типов — идеально. С точки зрения домена — катастрофа. Что такое role? Какие значения допустимы? Что означает пустая строка? Типы молчат. Ошибки — нет.

❗️ Типизированный хаос — всё ещё хаос

API может быть:
— перегруженным
— непоследовательным
— с неочевидными побочными эффектами
— и при этом идеально типизированным

doStuff(data, options, flags, ctx)

❗️ Типы не заменяют дизайн, лишь фиксируют этот бардак в коде

Если API:
— принимает «объект всего»
— возвращает any-подобные структуры
— заставляет знать внутренности системы

Плохой интерфейс + типы = плохо типизированный интерфейс.

❗️ Типы не объясняют, как пользоваться API

TypeScript не отвечает на вопросы:
— в каком порядке вызывать методы
— какие комбинации валидны
— что можно делать, а что нельзя

Если без документации API непонятен — типизация не спасёт.

❗️ Типы часто скрывают архитектурные проблемы

Когда видишь:
— гигантские union-типы
— Partial<T> поверх всего
— бесконечные дженерики

Это не «сложно». Это симптом.

❗️ Как типы усиливают хороший дизайн, а не маскируют плохой

Типы работают, когда:
— API маленький
— ответственность чёткая
— доменные ограничения выражены явно
— названия говорят сами за себя