Иногда кажется, что свободного времени просто нет: одни встречи, задачи и бесконечные «срочно».

Но свободный слот всё-таки существует. Главное — провести его с пользой 🚀

«Свободный слот» — подкаст команды AvitoTech для IT-специалистов, которые уже работают в роли лидов или присматриваются к управленческому треку.

В выпусках обсуждают то, с чем каждый день сталкиваются техлиды, тимлиды и менеджеры в технологических компаниях:
➡️ как принимать решения в условиях неопределённости;
➡️ что делать, когда задач больше, чем ресурсов;
➡️ как расти в роли и не терять интерес к профессии;
➡️ как справляться с ответственностью, которая растёт вместе с ролью.

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

Если вы работаете в IT, управляете процессами и людьми (или только примеряете эту роль) — возможно, вам сюда.

🎤 «Свободный слот» от AvitoTech

🔎 Feature-based vs Layered архитектура: что выбрать для фронтенда?

Когда вы начинаете проект, всё кажется довольно простым. Но потом начинаются проблемы. Архитектура фронтенда может быть выбрана так, что она сначала удобна, а потом превращается в настоящую головную боль. Сегодня давайте разберёмся, чем отличается feature-based подход от layered архитектуры и где каждый из них действительно работает.

➕ Layered архитектура

Layered архитектура — это та самая классика, с которой все когда-то начинали. Всё в проекте делится на слои: компоненты, сервисы, store, api и утилиты.

• Это удобно на старте, и легко понять новичкам, потому что структура очевидна и проста. Но когда проект начинает расти, появляется куча проблем. Например, если вам нужно внести изменения в бизнес-логику, то придётся таскаться по пяти разным папкам. Вроде бы просто, но на деле начинается путаница.

• Пример, который я часто встречаю: добавление функционала «избранного». UI живёт в папке components, запросы — в api/favorites, а состояние в store. Функция вроде как есть, но она размазана по всему проекту, и найти все её части в одном месте просто невозможно.

➕ Feature-based архитектура

В feature-based архитектуре всё куда проще: каждый функционал — в своей папке. Структура выглядит примерно так:

/features
/favorites
ui/
api/
model/
lib/

• Здесь вся фича собрана в одном месте: UI, API и модель. Это даёт отличный контроль за кодом, упрощает рефакторинг и удаление функций, и делает работу с фичами понятной и изолированной. Всё, что связано с конкретной фичей, будет в её папке, и даже если вам нужно её удалить — вы просто стираете папку. Меньше глобального шума и больше порядка.

• Однако, как и в любом подходе, тут тоже есть свои нюансы. Например, если фичи слишком маленькие, это может привести к дублированию логики. Плюс, нужно чётко следить за границами и договориться с командой, что стоит делать фичами, а что нет.

➕ Как это выглядит на практике?

В больших проектах, как правило, не бывает чистых подходов. Очень часто используется гибрид: папки для инициализации, провайдеров, бизнес-сущностей и пользовательских сценариев.

• Такой подход позволяет сбалансировать бизнес-логику и не превращать папку shared в помойку, сохраняя возможность масштабирования.

• Когда стоит выбрать какой подход? Если проект маленький, срок жизни короткий и работает 1-2 человека, то layered будет вполне хорош. Но если продукт живёт долго, несколько команд работает над ним, а фичи часто меняются — feature-based будет предпочтительнее.

📌 Если вам нужно часто вносить изменения в одну фичу, и для этого нужно лезть во все уголки проекта, значит архитектура выбрана неправильно. Лучший признак правильного решения — это когда фичу легко найти, изменить и удалить, а дальше уже детали.

🚪 Frontender's notes

📂 AIKit: библиотека интерфейсов для ИИ-ассистентов на базе Gravity UI

ИИ-ассистенты сегодня появляются в десятках продуктов, и почти в каждом им нужен свой чат-интерфейс. Проблема в том, что такие интерфейсы часто пишутся с нуля — с разной логикой рендера, стриминга и обработки ошибок. Команда Яндекса решила эту задачу, создав в опенсорс AIKit — библиотеку компонентов для построения унифицированных UI-чатов на базе Gravity UI.

👁 Что такое AIKit:
AIKit — это набор React-компонентов, хука и утилит, который позволяет собрать интерфейс чат-ассистента за пару дней.
Он не зависит от конкретного провайдера ИИ (OpenAI, YandexGPT и др.) и подходит для любых сценариев общения с моделью.

👁 Основные принципы архитектуры:
• Atomic Design — компоненты собраны по уровням (атомы, молекулы, страницы), легко переиспользуются.
• SDK-agnostic — логика UI не привязана к конкретному API.
• Типизированные сообщения — user, assistant, tool, thinking и свои кастомные типы.
• Темизация и локализация встроены из коробки.
• Доступность — поддержка ARIA, навигация с клавиатуры, визуальные тесты через Playwright.

📝Как работает AIKit

UI принимает данные извне, поэтому состояние можно хранить в React State, Redux или MobX. Для типовых задач есть готовые хуки:

useSmartScroll() // умная прокрутка истории
useDateFormatter() // форматирование дат сообщений
useToolMessage() // обработка сообщений-инструментов

📌AIKit делает разработку ассистентов не просто быстрой, а единообразной.
Теперь у ИИ-чатов Яндекса — один язык интерфейса и одна база компонентов.

🚪 Frontender's notes

🤖 Исследователи разослали 37 000 фейковых резюме выпускников и посмотрели, кого чаще зовут на интервью

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

— Стажировки, ориентированные на развитие софт скиллов — причем даже в откликах на аналитические вакансии.

— Учёба за границей ожидаемо также повышает шансы найти быстро свою первую работу.

— Программирование + анализ данных дает жирный плюс к коллбэкам. При этом по отдельности эти навыки эффекта не имеют.

✖️ xCode Journal

🦾 Фронтендеры, забираем

Это огромный репозиторий с классными анимированными иконками, которые постоянно пополняются.

И да — всё опенсорс, так что смело можно использовать в своих проектах.

✖️ xCode Journal

❌ Когда useMemo и useCallback делают только хуже

Все любят useMemo и useCallback. А точнее, все любят думать, что они ускоряют приложение. Но проблема в том, что в реальных проектах они часто могут ухудшить производительность, а не улучшить. Давайте разберёмся, когда эти хуки на самом деле становятся более вредными, чем полезными.

🗳 Оптимизация, где её нет

Начнём с того, что если компонент и так рендерится быстро, то использовать useMemo не имеет смысла. Эти хуки добавляют ненужную работу: React всё равно должен хранить зависимости, сравнивать их и поддерживать ссылки в памяти. А для чего? Чтобы оптимизировать то, что и так работает нормально? Это самый популярный антипаттерн, с которым сталкиваются почти все фронтендеры.

📝 Мелкие вычисления — не повод для мемоизации

Если у вас маленькие данные, скажем, маппинг массива из пяти элементов или простая проверка условия в JSX, не стоит заморачиваться с мемоизацией. Затраты на выполнение useMemo зачастую превышают само вычисление. Да, мемоизация звучит красиво, но если её использовать без причины, то она только замедлит ваше приложение.

⬅️ «useCallback ради useCallback»

Очень частая ситуация: оборачиваем колбэк в useCallback, думая, что это спасёт нас от лишних рендеров. Но на самом деле, если эта функция не передаётся в memo-компонент и не участвует в зависимостях эффектов, то useCallback просто создаёт лишний шум в коде, не давая ни улучшений в производительности, ни каких-то других плюсов.

🔃 Нестабильные зависимости

Проблема с useMemo часто возникает, когда вы используете массивы или объекты в зависимостях. Это ведёт к тому, что мемоизация срабатывает на каждом рендере. По сути, вы усложняете код, не получая реальной пользы от мемоизации. В таких случаях лучше не усложнять.

❗️ Ломается читаемость

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

🔫 Иллюзия оптимизации

Самая опасная ошибка — это когда вы начинаете думать, что «всё оптимизировано», потому что начали использовать useMemo и useCallback везде. Но настоящие проблемы обычно кроются в лишних рендерах из-за стейта, тяжёлых эффектах, layout thrashing и, конечно же, неправильной архитектуре компонентов. Эти проблемы не решаются хуками.

📌 Помните, что оптимизация не всегда требует использования дополнительных хуков. Прежде чем применять эти инструменты, важно понять, действительно ли это необходимо. Оптимизация должна быть направлена на уменьшение лишней работы, а не на усложнение кода.

🚪 Frontender's notes

➡️ Memory leaks в браузере: реальные примеры из жизни

Утечки памяти в браузере — тема, про которую все слышали, но всё равно не все умеют их ловить. И если вы думаете, что это какая-то экзотика, то у вас есть шанс попасть в ловушку типичных ошибок. Особенно в продакшене, когда код выглядит нормальным, но в какой-то момент начинаются сюрпризы. Давайте рассмотрим распространённые кейсы, с которыми сталкиваются в реальных проектах.

ℹ️ Неудалённые event listeners

Классика жанра — добавили обработчик событий через addEventListener, но забыли удалить его через removeEventListener. Особенно больно это сказывается в SPA, где компоненты монтируются и анмонтируются постоянно. Узел DOM удалён, а вот ссылка на него всё ещё висит в памяти. Это приводит к её утечке, и рано или поздно начинаются проблемы с производительностью.

ℹ️ Таймеры и интервалы

Друзья, это тихие убийцы памяти. Таймеры, такие как setInterval или setTimeout, если их не очистить, продолжают работать, даже если компонент уже ушёл. Это особенно часто встречается в аналитике, в кастомных хуках или при постоянном опросе (polling). Всё это прекрасно работает в момент разработки, но на проде может быть источником медленного роста потребления памяти.

ℹ️ Замыкания, которые не отпускают

Замыкания штука полезная, но иногда они держат объекты, которые вам уже не нужны. Особенно это происходит в обработчиках событий и колбэках. Например, функция, которая обрабатывает какой-то клик, может случайно держать ссылку на большой объект или даже на весь стейт. Это и есть утечка памяти. Вы не видите этого напрямую, но память накапливается, пока не наступает момент, когда приложение начинает тупо тормозить.

ℹ️ Detached DOM nodes

Одна из самых неприятных утечек. Это когда DOM-нода вроде бы удалена со страницы, но из JS на неё всё ещё есть ссылка. В DevTools можно увидеть такие ноды как Detached HTMLDivElement. Это часто происходит, когда вы работаете с DOM напрямую или используете сторонние библиотеки. При этом браузер думает, что элемент ещё на странице, и не освобождает память.

ℹ️ Кэши без очистки

Сетку данных или просто в память — встраиваем кэш, чтобы «ускорить» работу приложения, но забываем о сроках жизни данных. Сет, мап, in-memory cache. Всё это растёт линейно со временем работы приложения, если нет стратегии очистки. Особенно часто это встречается в data-layer или при оптимизациях, где забывают про TTL (Time To Live) или лимиты на размер кэша.

ℹ️ Глобальный стейт как свалка

Глобальные сторы и синглтоны. Эти штуки остаются живыми на протяжении всего жизненного цикла приложения и могут продолжать хранить данные, которые уже не актуальны. Например, данные старых экранов, пользователей или сессий. Всё это ведет к накоплению лишней памяти и, как следствие, к утечке.

ℹ️ Проблемы с третьими библиотеками

Работа с внешними библиотеками тоже может привести к утечкам. Особенно если библиотеки не рассчитаны на частую монтировку и анмонтировку компонентов. Например, слайдеры, графики, аналитика. Всё это может не чистить свои обработчики событий или подписки на обновления, и, как результат, утечка памяти. Чинить её приходится вам, а не разработчикам этих библиотек.

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

🚪 Frontender's notes

Северокорейские хакеры из Lazarus Group вышли на новый уровень

Теперь они заражают разработчиков не через сомнительные ссылки, а через функции самого VS Code. Как работает схема:

— Вам пишет «рекрутер» с жирным оффером мечты в крипто-проект;
— Просят склонировать репозиторий с GitHub, чтобы «пофиксить баг» или «оценить код»;
— Вы открываете папку в VS Code, и редактор спрашивает: «Do you trust the authors?». Как только вы жмете «Yes» — маховик заражения запущен.

В папке .vscode лежит файл tasks.json с параметром runOn: folderOpen. В ту же секунду, как вы открыли проект, VS Code в фоне запускает вредоносный скрипт.

✖️ xCode Journal

🎭 Как даже оптимизированные сайты могут дико бесить пользователей

У тебя может быть быстрый сайт с зелёными метками в Lighthouse, но если пользователи начинают ругаться из-за того, что кнопка прыгает в самый неподходящий момент, значит, где-то закралась проблема с Layout Shift (CLS). Давайте разберёмся, как это происходит и почему это так критично.

ℹ️ Причины CLS даже на «оптимизированных» сайтах

• Картинки без размеров
Это классика. Когда изображения не имеют явно заданных width, height или aspect-ratio, браузер не понимает, сколько места нужно выделить для картинки. В итоге контент загружается, а потом резко подстраивается под новое изображение. Проблема особенно остро стоит на сайтах, где изображения грузятся после первого рендера.

• Динамический контент выше фолда
Если после первого рендера появляются блоки контента, такие как баннеры, алерты или cookie-плашки, всё это смещает элементы, которые уже были загружены. Оптимизация по загрузке — это не всегда оптимизация для UX.

• Web-шрифты без стратегии
FOIT и FOUT — это старые враги всех, кто пытался делать быстрые сайты. Когда шрифт подгружается после рендеринга и имеет другие метрики, текст «прыгает», и появляется тот самый раздражающий Layout Shift. Чтобы этого избежать, нужно использовать font-display, правильно настраивать fallback-стек и подбирать правильные метрики шрифтов.

• Skeleton-и без реальных размеров
Скелетоны случаются, когда вместо контента сначала показывают каркас страницы. Но если этот каркас не совпадает по размерам с финальным контентом, это превращается в очередной отложенный Layout Shift. Это может выглядеть красиво, но с точки зрения пользователя опыт взаимодействия оставляет желать лучшего.

• Рендеринг на клиенте без резерва места
Когда компонент появляется после загрузки данных, а место под него не зарезервировано, всё на странице сдвигается. Это особенно часто встречается в React-приложениях с условным рендерингом.

ℹ️ Почему Lighthouse не всегда спасает?

Даже если в Lighthouse всё зелёное, проблема с CLS может проявляться только в реальных сценариях, на медленных сетях или при определённых A/B тестах. Локально всё может быть идеально, а в продакшене пользователи начнут жаловаться.

ℹ️ Для того чтобы избавиться от этого раздражающего поведения:

• Всегда резервируй место под контент
• Используй aspect-ratio для изображений
• Контролируй, когда появляются динамические блоки
• Настраивай правильную загрузку шрифтов
• Проверяй CLS в реальных условиях, а не только в отчётах

📌 CLS не только про скорость сайта, но и про доверие пользователей. И как только этот доверительный момент будет подорван, даже самую оптимизированную страницу они покинут. Поэтому важно не только следить за метками в Lighthouse, но и тестировать на реальных данных, чтобы избежать неприятных сюрпризов.

🚪 Frontender's notes