ТОП - Тёма о программировани

Здарова, работяги!

Кто собирается на Avito.Tech.Conf 26 сентября?

Я уже рассказывал про конфу. Напомню, что мне самому особенно интересно в программе: AI в SDLC, настройка процессов и управление командой.

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

Рядом доклад «Как реально меняется PDLC или почему вы ускоряете не то, что нужно». Уже по названию хочется послушать. С моим интересом к канбан-методу и теории ограничений пройти мимо сложно.

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

Конфа пройдёт в Москве, будет и онлайн. Программа и регистрация — здесь.

Кто идёт — пишите в комментариях. Если собирались, но не с кем, можно найти компанию прямо тут.

Зачем ты пишешь?

Здарова, работяги!

Помню, как все только начинали активно использовать агентов. Только начинали пробовать скиллы для брейншторма и т. д. Я был шокирован этими огромными документами, где предусмотрена куча всего, всё проверено по доке и т. д. Смотришь и сразу понимаешь — солидно! Хочется довериться такому решению!

Откуда это? Откуда такая вера в такие решения? Я долго думал, предполагаю, что мы привыкли: если коллега написал такой подробный документ, предусмотрел столько всего и так расписал решение, то он реально заморочился, провёл ресерч, и чаще всего это действительно крутая работа. Хз как у вас, но в моей практике чаще всего так и было.

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

Но самое страшное тут ещё и то, что желание скипнуть чтение подкрепляется ещё и ленью. Я сразу вспоминаю всякие лицензионные соглашения и подобное — ты, значится, собрался поиграть в игру, которую долго ждал, а тебе тут пихают кучу страниц текста. Что за чёрт?! Окаем и погнали!

Можно сказать, что я использую плохие модели... Фейбл, Астра, Опус, ГПТ Сол... Ну хз тогда, какие хорошие. Можно сказать, что я не умею их использовать... Ну мб)

Хочу ли я сказать, что ИИ — ерунда? Точно нет. ИИшка отлично умеет писать и лаконичные, продуманные короткие решения.

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

Вот такие вечерние мысли... Всем доброй ночи!

Здарова, работяги!

Приезжает коробка. Внутри бейдж на Avito.Tech.Conf и часы «Ракета».😳

И тут я немного завис)) Такие посты я раньше видел у айтишных блогеров: курьер, коробка, распаковка. А себя блогером никогда не считал и не собираюсь. Канал у меня чисто для души и мыслей: пишу про то, что делаю на работе, во что упёрся, что по дороге понял. Ни контент-плана, ни «прогревов», ни курсов «войти в айти» (или что там сейчас в моде — «войти в ИИ»). И вот коробка приехала ко мне. Ладно, приятно.

Разбор часов от меня не ждите. Я в них не разбираюсь, на руке у меня годами только Garmin да Whoop: пульс, сон, восстановление — вот это мне важно, а не красивые циферблаты, истории и статус. Но подарок приятный и неожиданный: такого приглашения на конфу мне ещё не присылали (да будем честны, вообще никаких ещё не присылали🤣). Кому интересна история самих часов — коллеги по каналам уже расписали, я лучше про конференцию.

Про Avito.Tech.Conf я уже писал: 26 сентября, Москва, AG Loft, есть онлайн. Это конфа для лидов и менеджеров. В этом году кроме обычных докладов ребята добавили игровые форматы: рабочие кейсы разбирают за покерным столом, нетворкинг — за бильярдом. Звучит странно, но, кажется, именно так и разговорятся те, кто на обычном нетворкинге стоит у стены с кофе.

Регистрация по ссылке. Кто собирается — напишите, найдёмся на месте.

Здарова, работяги!

Потихоньку продолжаю дописывать посты из заметок. В прошлый раз — элементы и файберы, то есть где React держит работу. Теперь — что он с ней делает, когда прилетает обновление. И почему я больше не сужу по счётчику ререндеров, хотя четыре года назад сам учил их считать.

Обновление идёт в две фазы

Render-фаза: React идёт по файберам, зовёт функции компонентов и сверяет свежие элементы с прошлыми. Весь код из тела компонента крутится здесь, чистый JS. Commit-фаза: разница применяется к DOM, тут же бегут useLayoutEffect. Разницы нет — DOM не трогается.

У браузера свой рендер — раскладка и пиксели, и он нужен, только если коммит реально тронул DOM.

Отсюда тезис: вызов функции копеечный, дорого то, что в её теле.

Пример

function Search({ products }) {
  const [query, setQuery] = useState('');

  return <>
    <input value={query} onChange={e => setQuery(e.target.value)} />
    <Results products={products} query={query} />
  </>;
}

function Results({ products, query }) {
  console.count('Results render');

  const rows = rankProducts(products, query); // тяжёлый расчёт
  return <Table rows={rows} />;
}

Вводим текст, счётчик растёт. Легко решить: Results ререндерится слишком часто, срочно в memo.

Но memo здесь даже не поможет: query меняется с каждым символом, а с ним и пропсы Results.

Счётчик отвечает не на тот вопрос

Консоль ответила на один вопрос: сколько раз React вызвал функцию. Сколько занял каждый вызов, дошёл ли результат до DOM, из-за React ли вообще тормозит — этого в ней нет.

Один вызов функции не равен одному изменению экрана. Под <StrictMode> в dev счётчик удваивается сам по себе. С транзишенами (`startTransition`, `useDeferredValue`) React может прервать или выбросить начатый проход: лог остался, результата нет. В примере их нет — ввод срочный и рендерится синхронно.

Бывает и наоборот: Results вызвался один раз, но rankProducts занял столько, что ввод стал дёрганым. По счётчику эти случаи не различить.

При этом счётчик не бесполезен: «рендерится ли оно вообще без нужды» он показывает за пять секунд. Молчит про то, сколько это стоит.

Что я измеряю вместо этого

Открываю Performance в Chrome, запись, один символ в поле, стоп после обновления таблицы. Трейс ровно того сценария, который тормозит.

На dev-сборке React 19.2+ там сами появляются React Performance tracks, без расширения. Scheduler показывает, срочное обновление или фоновое, и сколько заняли Render, Commit и эффекты; Components — сколько заняли конкретные компоненты и их эффекты. Рядом — обычный JS, layout и paint браузера.

На React до 19.2 — вкладка Profiler в React DevTools: flamegraph по коммитам плюс настройка «Record why each component rendered».

На моём демо к посту один символ — это «+2» в консоли и около четверти секунды на каждый вызов Results на треке. Первое ни о чём, второе — уже диагноз.

Что делать дальше, трек тоже подсказывает:

— широкий Render в Results, а пропсы реально поменялись: memo не спасёт, лечу сам расчёт;
— React отработал быстро, а дальше тянутся layout и paint: ререндеры ни при чём, смотрю, что коммит сделал с DOM;
— Results дёргается часто, но копейками: оставляю в покое.

Где это ломается

Dev-сборка медленнее боевой: проверки, двойной рендер Strict Mode, инструментация. Трейс тут ищет подозрительное место, а не точные цифры — за ними в профилировочную сборку.

И трейс — про одно взаимодействие. Копеечный рендер на каждый скролл в нём выглядит невинно, а в сумме уже нет. Если поддерево от изменившегося стейта не зависит, его render лучше не запускать вовсе — это про структуру дерева и colocation, следующий пост.

Резюме

— render — чистый JS, DOM меняется в коммите, браузер рисует, только если коммит что-то тронул;
— количество вызовов не показывает задержку: вызов копеечный, дорого то, что внутри;
— сначала записать одно тормозящее взаимодействие и найти дорогой этап, потом оптимизировать;
— счётчик остаётся для вопроса «рендерится ли вообще» — с него начнётся пост про colocation.

Здарова, работяги!

Совсем скоро осень, а значит, начинается сезон конференций.

Про Avito.Tech.Conf я уже рассказывал. В октябре поеду в Санкт-Петербург на HolyJS уже в роли спикера — про доклад и подготовку напишу отдельно. А 5 сентября пройдёт Deep Tech Night — о ней сегодня и расскажу.

Мне Deep Tech Night особенно интересна: AI-агенты сейчас напрямую связаны с моими проектами и ежедневными задачами.

По-моему, спор «AI — это рабочая технология или очередной хайп» уже немного протух. В исследовании DORA за 2025 год 90% опрошенных технических специалистов использовали AI в работе, больше 80% говорили о росте продуктивности. Но важнее главный вывод самого исследования: AI работает как усилитель. Он усиливает уже существующие сильные стороны и дисфункции организации. В хорошем процессе буст превращается в результат для команды, а в слабом его съедают узкие места и быстрее растёт техдолг.

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

AI всё-таки не новая библиотека. React может заметно изменить архитектуру фронтенда. А AI влияет на весь цикл разработки — от идеи до её релиза в прод.

Поэтому меняется весь SDLC. Кто готовит контекст для агента? Что ему можно делегировать? Где нужен человек? Как проверять результат и чем вообще измерять эффект?

И это не только мои вопросы. В Яндексе уже ставят конкретные цели по встраиванию AI в разработку. Например, запустили программу 75/75/75: к концу 2026 года не менее 75% разработчиков должны регулярно использовать AI, он должен участвовать не менее чем в 75% изменений и генерировать не менее 75% кода в каждом из них.

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

Больше всего я хочу послушать Андрея Попова с докладом «AI и продуктивность в Яндексе: что реально заработало». Ребята год измеряли влияние AI на работу разработчиков. Мне интересно, что именно измеряли, с чем сравнивали и какие практики в итоге дали результат.

Но мне важно не только разобраться с текущими процессами, но и понять, как AI будет менять разработку дальше. Поэтому хочу послушать Мо Гавдата, ex-Chief Business Officer Google X, с докладом «За пределами LLM: что дальше после первого поколения AI-систем» — как раз о том, что ждёт нас после первого поколения AI-систем.

Если тема вам близка — залетайте в онлайн: там будут трансляции докладов и Q&A со спикерами. Программа и регистрация — по ссылке.

Здарова, работяги!

Сейчас я много думаю про AI-native команды и внедрение ИИ в разработку. Речь не про «выдали всем доступ к Claude — теперь мы AI-native», а про то, как меняется сам процесс разработки: какие практики приживаются и где всё это ломается. Тут особенно интересен опыт из первых уст: что другие команды уже попробовали, что у них сработало и от чего пришлось отказаться.

Поэтому мне и интересна Avito.Tech.Conf. Это конференция для лидов, а в программе кроме докладов будут воркшопы и мастермайнды. Можно будет пообщаться с коллегами и расспросить, как они перестраивают работу своих команд.

Мероприятие пройдёт 26 сентября в Москве, в AG Loft. Для тех, кто не сможет быть очно, будет онлайн-трансляция. Зарегистрироваться можно по ссылке

До конференции Avito.Tech вместе с Buenos Padel ВДНХ организовали бесплатные игры в падел. Поиграть можно с 20 августа до 13 сентября.

Я играю в большой теннис, а падел ещё ни разу не пробовал. Тут соблазнился и записался на 23 августа в 19:00. Посмотрим, насколько этот опыт пригодится. Если тоже хотели попробовать или хотите поиграть вместе — регистрируйтесь на конференцию и приходите на падел, на этот слот ещё есть места.

стартуем

🍿 АНОНС СТРИМА 20 июня в 14:00 по мск

twitch — youtube — vk

Здарова, работяги!

Завтра(14:00) на стриме с @siberiacancode пообщаемся на тему агентов в разработке. Забегайте, задавайте вопросы(не только про агентов) 📞

Здарова, работяги!

Я уже рассказывал вам про скиллы: зачем они и как их писать.

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

Что там уже есть:

— socratic-tutor — в последние месяцы я активно использую агента в повторении универской программы и прочей базы, прокачке в систем-дизайне и разборе технологий, которые я раньше не трогал. Для этого я собрал себе реп и постепенно накапливал там рулы и скиллы, отлаживал их и допиливал. Этот скилл родился из этого репозитория как обезличенная выжимка. Я попробовал обкатать его на чистом репе — мне зашло. Буду его допиливать по мере доработок родительского репчика. Скорее всего позже добавлю более специфичных туторов.

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

— challenge-talk — используется во флоу prep-talk, я использую и отдельно для челенджинга идей докладов. Он хорошо позволяет подготовиться к встрече с ПК конференции.

— fact-check — тоже входит в prep-talk. Проверяет утверждения, цифры и факты. Советую запускать на сильной модели.

— content-review — тоже из prep-talk. Проверяет ваш доклад на всякие водянистые фразы, пыль, пустые обещания и иишные фразочки. Лучше на сильной модели.

Велком! Буду рад вашим комментам по опыту использования.

Здарова, работяги!

Прошлые два поста были про сдвиг в голове: React всё меньше про «сравни деревья», всё больше про «какую работу и когда делать». Три поста на одной философии — перебор, так что ныряем под капот.

Начну с фундамента: с чем React вообще работает, когда рендерит. Звучит занудно, но пока тут чёрный ящик, советы про memo и colocation остаются заклинаниями: делай так, а почему — непонятно.

JSX — это объект-описание

<ChildVerySlow /> сам по себе ничего не рисует. Это сахар над вызовом функции, которая возвращает обычный объект:

<ChildVerySlow color="red" />
// превращается примерно в:
{ type: ChildVerySlow, props: { color: "red" }, key: null }

Чертёж: какой компонент и с какими пропсами показать. Эти объекты одноразовые — на каждом рендере создаются заново и выбрасываются. Хранить в них что-либо нельзя, да и негде.

Файбер — рабочая память React

А жить-то где-то надо. На каждый узел дерева — компонент, div, даже кусок текста — React заводит файбер: объект, который переживает рендеры.

В нём лежит всё, что должно пережить вызов функции: пропсы прошлого рендера, ссылки на родителя, ребёнка и соседа, пометки «здесь запланирована работа».

Деревьев из файберов два: текущее, по которому построен экран, и рабочее (work-in-progress из старой лекции), которое React собирает под обновление. В коммите React переключает указатель: достроенное рабочее дерево становится текущим. Старые файберы не выбрасываются — из них, переписав поля, React соберёт следующее рабочее дерево.

Стейт — связный список хуков

Локальный стейт тоже живёт в файбере. Никакой магии: на каждый вызов хука React заводит обычный объект, где лежит значение и ссылка на следующий хук. Вместе они сцеплены в связный список:

// fiber.memoizedState, упрощённо:
hook1 = { memoizedState: 'Тёма', next: hook2 }
hook2 = { memoizedState: 29,     next: null  }

Имён у звеньев нет. На новом рендере React идёт по списку заново: первый вызов хука получает первое звено, второй — второе. Всё сопоставление держится на порядке вызовов. Поэтому хукам нельзя жить в условиях:

function Profile({ isEditing }) {
  const [name, setName] = useState('Тёма');
  if (isEditing) {
    const [draft, setDraft] = useState(name); // хук под условием
  }
  const [age, setAge] = useState(29);
}

Пока isEditing выключен, в списке те самые два звена. Включился — вызовов стало три. draft молча заберёт второе звено и получит 29 — чужой стейт age. А третий вызов упрётся в конец списка, и React упадёт с той самой «Rendered more hooks than during the previous render».

В лучшем случае рендер падает сразу, в худшем — стейт тихо съезжает в чужие звенья. «Хуки только на верхнем уровне» — не вкусовщина линтера, а прямое следствие того, как стейт лежит в файбере.

Зачем дерево распилено на файберы

До Fiber React рендерил рекурсией: зашёл в корень и спустился до самых листьев. Из середины рекурсии не выйти — стек вызовов на паузу не поставишь.

Файберы разворачивают рекурсию в плоский цикл. Вместо стека — те самые ссылки на родителя, ребёнка и соседа плюс указатель, на каком файбере остановились. Один шаг цикла — обработать один файбер, в исходниках он так и называется: performUnitOfWork. После любого шага React может отложить дерево, заняться срочным и продолжить с того же места. Управляемая срочность из прошлого поста стоит ровно на этой структуре.

В следующей части — что происходит, когда по файберам идёт рендер: две фазы, чем рендер React отличается от рендера браузера и почему ререндер дёшев, а дорог код внутри.

Резюме

— JSX-элемент — одноразовое описание { type, props, key }: создаётся на каждом рендере и выбрасывается;
— файбер — объект, который переживает рендеры: прошлые пропсы, ссылки по дереву, список хуков;
— хуки сопоставляются со звеньями списка только по порядку вызова, поэтому им нельзя жить в условиях;
— дерево обходится по одному файберу за шаг, между шагами React может прерваться — на этом стоит управляемая срочность.

Здарова, работяги!

Раньше я, как и все, искал одну лучшую модель. Выходит новая — в чатиках вопрос «что сейчас топ». Одна шкала: от «тупее» к «умнее».

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

Вот тут одна шкала и рассыпалась. В оркестрации модель выбирается не «лучшая вообще», а подходящая под роль: где-то важнее скорость, где-то формат, где-то глубина, где-то цена.

Две оси вместо рейтинга

Я развёл выбор на две вещи.

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

Вторая — масштаб и автономия: сколько шагов, сколько надо думать, насколько без присмотра.

Рейтинг «кто умнее» пытается свести эти оси в одно число. Мне всё чаще не хватало ответа «бери вот эту модель»: без роли и масштаба он мало говорит.

Характер задачи → семейство

У семейств часто заметен разный характер: какие промпты модель лучше держит и где она у меня чаще окупается.

— Claude-like модели (Claude Sonnet, Opus, Haiku, Kimi, GLM) — аккуратные исполнители. Хорошо держат план, чеклист и явный формат вывода.
— GPT-like модели (GPT-5 mini, GPT-5, GPT-5.5, DeepSeek) — про автономное рассуждение. Лучше держатся там, где план ещё надо достроить: выбрать подход и не развалиться без маршрута на каждый шаг.
— Gemini-like модели (Gemini Flash, Gemini Pro, Qwen) — сильны в визуале. Я беру их туда, где есть UI, скриншоты, макеты и визуальные баги.

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

Масштаб задачи → размер модели

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

— Утилиты: найти файл, суммаризировать, сделать простую правку. Тут важнее скорость, цена и стабильный минимум качества. Примеры: Haiku, GPT nano / mini-fast, Gemini Flash, MiniMax highspeed.
— Рабочая лошадка: обычная фича, ревью, средний рефактор. Примеры: Sonnet, GPT mini, GLM, Kimi.
— Глубокая автономная работа: архитектура, оркестрация, многошаговая задача, где план уточняется по дороге. Примеры: Opus, старший GPT-5, Gemini Pro.

В промпт-левел оркестрации это превращается в простое правило:

explore: утилита → gpt-5-mini-fast → minimax-highspeed
deep: глубокая работа → gpt-5.5 → opus → gemini-pro

Сначала роль, потом масштаб, потом конкретные модели. У поиска задача короткая, поэтому туда идут быстрые модели. У deep-агента работа длинная, поэтому цепочка начинается с флагманов.

Частые ошибки

— Поставить флагман на утилиту. «Пусть поиск по файлам делает Opus, чтоб уж точно не ошибся». Дороже, медленнее, а качество почти не меняется.
— Отдать глубокую задачу быстрой мелочи. На одном шаге — может быть. Но на длинной работе модель начинает плыть: теряет нить, меняет план на ходу, забывает свои же решения.

Важные уточнения

Первое: флагманы почти универсальны. Не хочешь возиться с осями — поставь Opus или старший GPT-5 на всё, и оно поедет. Эта классификация про эффективность: деньги, скорость и стабильность на потоке.

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

Третье: модель редко работает сама по себе. На результат влияет харнес: Cursor, Claude Code, omo и тд; промпты, инструменты, контекст. В хорошем харнесе модель попроще часто обходит флагман в голом чате.

Резюме

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

Здарова, работяги!

Продолжаем про React.

Если бы я сейчас пересобирал старую лекцию про React, я бы начал не с FPS.

Тогда я заходил через плавность интерфейса: пользователь нажал кнопку, ввёл текст, открыл попап — интерфейс должен ответить без подвисаний.

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

Старый заход

В той лекции я шел через 60 FPS.

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

Это не устарело. Просто 60 FPS — слишком грубая рамка, если на ней остановиться.

Fiber в этой истории был ответом на проблему: React перестал воспринимать рендер как один большой кусок работы. Новое дерево можно готовить частями, а не в режиме «начали — теперь все ждут».

Эта база держится. Если вы заблокировали главный поток тяжёлым JS, пользователю всё равно будет плохо.

Но как объяснение современного React этого уже мало.

Чего здесь не хватает

Проблема не только в том, сколько работы делает интерфейс. Проблема ещё и в том, какая это работа.

Пользователь печатает в инпуте — символ должен появиться сразу. Иначе это ощущается не как «рендер не успел», а как сломанная клавиатура.

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

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

И это всё ещё правильный совет. Просто он не закрывает весь кейс. Иногда работа нужная, но пользователь не обязан ждать её прямо сейчас.

Что изменилось в модели

Современный React всё меньше похож на прослойку для обновления DOM и всё больше — на механизм управления работой интерфейса.

Не только:
— что изменилось;
— какие компоненты надо пересчитать;
— какие DOM-изменения потом применить.

А ещё:
— что должно ответить сразу;
— что можно подготовить в фоне;
— что можно прервать и начать заново;
— что вообще лучше не тащить на клиент.

Вот почему старая рамка 60 FPS стала тесной.

Пример такой фичи

startTransition — просто самый наглядный пример этой идеи.

Ввод в поле — срочный. Пересчёт тяжёлого списка по этому вводу — часто нет. Поэтому одно обновление должно пройти сразу, а второе может догнать позже.

Но это не пост про startTransition. Для него нужен отдельный разбор.

Важно отметить, что transition не делает медленный код быстрым. Синхронный фильтр на десять тысяч строк React не превратит в фоновую магию.

Так что старые инструменты никуда не делись: убирать лишнюю работу всё ещё надо. Просто теперь появился ещё один вопрос: что из оставшейся работы можно показать позже.

Как я бы объяснял сейчас

Раньше я бы больше давил на то, как React сам организует рендер: строит новое дерево, может прервать подготовку, потом одним куском коммитит результат.

Сейчас я бы добавил второй слой: разработчик тоже всё чаще участвует в разговоре о приоритетах. Что должно ответить сразу. Что можно подготовить позже. Где показать старый экран, пока новый ещё собирается.

Разница в формулировке маленькая, а в голове большая.

Потому что дальше в эту же рамку ложатся транзишены, Suspense, стриминг и Server Components. Это не просто набор новых фич, а попытка разложить интерфейс по границам: что сделать сразу, что догрузить потом, что можно прервать.

Вот это, по-моему, и есть главный сдвиг.

Резюме

— ограничение по времени на кадр всё ещё актуально, но это не вся история;
— современный React удобнее объяснять через вопрос: что делать сейчас, а что позже;
— React и раньше управлял рендером, но теперь разработчик чаще явно участвует в выборе приоритетов;
— главный вопрос теперь не только «как сделать меньше работы», но и «что пользователь должен увидеть сразу».

«Кто-то должен был это сказать!» — эта мысль не покидала нас, пока слушали новый сезон подкаста «Свободный слот» 🌟

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

А ещё у ребят есть канал — там они делятся мыслями, которые не попали в выпуски, полезными статьями и анонсами митапов. Очень советуем заглянуть!

Здарова, работяги!

Около четырёх лет назад я прочитал лекцию React(продвинутый) в ШРИ. Там был большой разбор про то, как React работает под капотом.

Лекция неожиданно для меня хорошо зашла: я-то её планировал на аудиторию студентов ШРИ, а получилось 92к просмотров. До сих пор люди иногда пишут, что именно после неё у них щёлкнуло понимание React, и это меня сильно мотивирует.

Потом я надолго почти перестал писать про React.
Причина простая: я несколько лет преподавал React, не только в ШРИ, и в какой-то момент накопилась усталость скорее от преподавания, чем от самой темы.

А пока отдыхал, React взял и уехал вперёд.

Что осталось прежним
Главная база из той лекции не умерла.

React всё ещё не “просто меняет DOM”. Он строит work-in-progress дерево, сравнивает его с текущим деревом, готовит изменения и потом коммитит результат.

Ререндер всё ещё не равен “браузер перерисовал весь экран”.

key всё ещё влияет на то, считает ли React компонент “тем же самым” между рендерами.

Ремаунт всё ещё может внезапно стереть локальный state.

Фаза коммита всё ещё не то место, где React может спокойно сказать: “ой, браузер занят, я продолжу позже”. Если дошли до применения изменений — надо применять.

То есть если вы тогда поняли идею current tree и work-in-progress tree, это знание не превратилось в тыкву.

Но сменился фокус
Раньше React часто объясняли через Virtual DOM.

Мол, React строит виртуальное дерево, сравнивает с прошлым, находит разницу и аккуратно обновляет настоящий DOM.

Как первая ступенька — норм. Как полная модель — уже слабовато.

Современный React всё меньше хочется объяснять через “сравнение деревьев” и всё больше через планирование работы.

Не просто:
— что изменилось;
— какой компонент ререндерится;
— сколько DOM-нод надо обновить.

А ещё:
— срочная это работа или нет;
— можно ли её прервать;
— можно ли показать старый UI, пока новый готовится;
— можно ли часть работы сделать на сервере;
— можно ли вообще не делать ручную мемоизацию, потому что её заберёт Compiler.

Вот это, по моему ощущению, главный сдвиг последних лет.

React стал не только библиотекой для описания UI. Он всё больше становится runtime-ом, который управляет тем, когда, где и с каким приоритетом этот UI должен появиться.

В старой лекции был классический пример:
родитель хранит count, рядом лежит тяжёлый ChildVerySlow, нажимаем кнопку — и внезапно страдает вообще не тот компонент, который визуально поменялся.

Решения тогда были понятные:
— изолировать state ближе к месту использования;
— не поднимать состояние без причины;
— следить за ремаунтами;
— аккуратно использовать React.memo;
— профилировать, а не гадать по ощущениям.

И это всё ещё хорошие советы.
Но теперь этого слоя знаний уже недостаточно.

React 18 принёс автоматический батчинг и конкурентный рендеринг. Появились startTransition и useDeferredValue. Suspense перестал быть просто красивой обёрткой вокруг lazy. Server Components поменяли вопрос с “как быстрее отрендерить на клиенте” на “а должна ли эта работа вообще попасть на клиент”. React Compiler начал двигать нас в сторону мира, где часть ручного memo, useMemo и useCallback становится внутренней заботой React, а не обязательной ручной работой разработчика.
Не магия. Не “теперь можно не думать”. Скорее наоборот: думать надо глубже и немного о другом.

Поэтому я хочу сделать серию постов про современный React через призму той старой лекции.
Не “что нового в React 18/19” списком из ченджлогов. А нормально, по-работяжьи:
— что из старой модели всё ещё держится;
— где старые объяснения стали слишком грубыми;
— как батчинг, транзишены и отложенный рендеринг меняют разговор про ререндеры;
— почему Suspense теперь не только про React.lazy;
— зачем нужны Server Components и почему use client нельзя расставлять на автопилоте;
— что React Compiler меняет в привычке мемоизировать всё руками.

Короче, будем снова залезать под капот React. Только уже не того React времён “хуки ещё выглядят свежей штукой”, а React, который пытается управлять всей жизнью интерфейса: от серверной работы до срочности обновлений на клиенте.

Здарова, работяги!

Сегодня разберёмся, в чём боль code-first, что меняет schema-first и как это выглядит в Fastify.

Code-first

Правила формы данных живут в коде, рассыпанные по разным местам. Валидация — отдельная функция. Типы — отдельный интерфейс. Обе сущности — копии одной и той же правды в разных синтаксисах.

Знакомая картина — ручная валидация формы:

function validateUserForm(values) {
  const errors = {}
  if (!values.email) errors.email = 'required'
  if (!values.age || Number.isNaN(+values.age)) errors.age = 'must be number'
  return errors
}

// где-то рядом
type UserForm = { email: string; age: number }

Два источника правды на одну сущность. Один обновил — другой забыл. Дальше прод, неприятный сюрприз, разбор полётов в Slack.

Schema-first

Подход, при котором описание формы данных живёт отдельно от бизнес-логики и является источником правды. Описываем форму декларативно — например, объектом JSON Schema. Дальше из этого объекта получаются:

— валидация входа (запрос проверяется по схеме до того, как попадёт в обработчик);
— сериализация выхода (ответ режется по схеме, лишние поля не уйдут наружу);
— TypeScript-типы (генерятся из схемы — например, через TypeBox или json-schema-to-ts).

Одна декларация — три артефакта. Обновил схему — всё остальное само догнало.

Как это в Fastify

Fastify построен вокруг schema-first из коробки. Минимальный пример:

const schema = {
  body: {
    type: 'object',
    required: ['email', 'age'],
    properties: {
      email: { type: 'string', format: 'email' },
      age: { type: 'integer' }
    },
    additionalProperties: false
  },
  response: {
    201: {
      type: 'object',
      properties: {
        id: { type: 'integer' },
        email: { type: 'string' }
      }
    }
  }
}

fastify.post('/users', { schema }, async (req, reply) => {
  const user = await db.users.insert(req.body)
  reply.code(201).send(user)
})

Что мы получили бесплатно:

— request body валидируется до обработчика. Невалидный — 400 с понятным сообщением, обработчик даже не дёргается;
— response сериализуется по схеме. Если в user внезапно прилетело password_hash — он не уйдёт наружу. Это и про безопасность, и про предсказуемость контракта;
— additionalProperties: false режет лишние поля на входе. Прислали лишнее — до обработчика оно не доедет. Если хочется именно 400, это уже настраивается через Ajv.

Бонусом — скорость

Под капотом сериализация ответа идёт не через JSON.stringify, а через fast-json-stringify: на старте по response-схеме компилируется специализированная функция, и дальше она работает в разы быстрее (в бенчах самой библиотеки — до 2x на типовых ответах). JSON.stringify каждый раз обходит объект на ходу и не знает заранее, какие поля в нём окажутся. fast-json-stringify знает структуру и идёт почти прямым проходом по известным полям. Платим за это одной компиляцией на старте — копейки.

Дока Fastify.

Резюме

— schema-first даёт один источник правды — декларацию данных, из которой вытекают валидация, сериализация и типы;
— code-first проще на старте, но копии одной правды быстро расходятся, и это всегда вылазит больно;
— в Fastify это работает из коробки, плюс бонусом сериализация в разы быстрее обычного JSON.stringify.

Понял, принял, делаем 👨‍💻

Здарова, работяги!

В прошлый раз говорили про скилы. Сегодня — про линтеры и форматтеры: как я выбирал стек на новом проекте, почему сначала взял Biome и почему переехал на oxlint + oxfmt.

Почему про линтеры

Как уже писал, прежде чем тащить guidance в скилы и рулы, стоит посмотреть, нельзя ли закрыть это автоматикой. Линтер — бесплатный детерминированный гейт: не забывает, не интерпретирует, не жжёт токены. Особенно ценно при работе с агентом — каждое правило в линтере = минус один пункт в guidance и минус один способ облажаться.

Что было на столе

— ESLint + Prettier — максимум правил и плагинов, но два тула, медленно, конфигурить долго.
— Biome — один тул на всё (lint + format + import sort), быстрый, конфиг простой.
— oxlint + oxfmt — Rust-стек от oxc: быстрый линтер с большим покрытием ESLint-правил и отдельный форматтер.

Сравнение коротко

— Скорость: oxlint > Biome >> ESLint+Prettier.
— Количество тулов: Biome — один. oxlint + oxfmt и ESLint + Prettier — два, но oxlint + oxfmt живут в одной экосистеме и конфигурятся проще.
— Покрытие правилами: ESLint — максимум. oxlint — большая часть популярных ESLint-правил, пул растёт. Biome — свой набор, заметно уже.
— Конфигурируемость: ESLint — максимум. oxlint — гибко, overrides, плагины. Biome — намеренно ограничено.
— Экосистема: ESLint — всё. oxlint — догоняет, ключевые плагины (react, typescript, import) уже есть. Biome — самодостаточно, плагинов нет.

Почему сначала взял Biome

Просто, быстро, один тул. На старте проекта это закрывает 90% потребностей с нулевой настройкой.

Почему слез

Пожил пару недель и понял, что правил банально не хватает.

— Нет аналога consistent-type-assertions. Запрет as SomeType — критичное правило, потому что агенты обожают кастить типы вместо того, чтобы написать type guard или поправить сигнатуру. Без линтера это ловится только на ревью, и то не всегда.
— Слабый no-restricted-imports. Хотелось паттернами фиксировать границы модулей в монорепе — в Biome либо никак, либо очень куцо.
— Нет react/no-multi-comp и подобных мелочей, которые модель регулярно норовит нарушить.
— overrides по glob сильно ограничены, не получается тонко настроить правила под разные части репы.

В итоге половину инвариантов пришлось бы тащить в AGENTS.md как текстовое правило — а это ровно то, чего стараюсь избегать.

Переход на oxlint + oxfmt

— Все важные ESLint-правила, которых не хватало, есть из коробки.
— overrides по glob позволяют жёстко зафиксировать границы между приложениями и пакетами в монорепе.
— Скорость на уровне Biome, на больших прогонах даже лучше.
— AGENTS.md похудел: куча пунктов уехала в линтер.

Форматтер (oxfmt) пока проще биомовского, но мне его хватает.

Резюме

— При работе с агентами линтер обязателен.
— Biome — отличный выбор для небольших проектов, пока хватает встроенных правил.
— ESLint + Prettier сейчас не вижу смысла брать: медленнее, конфигурить дольше, а у oxlint уже хорошее покрытие правил.
— oxlint + oxfmt — мой текущий дефолт.

Пост фана и чутка рекламы 🚶

Я сам не из Москвы: приехал сюда учиться примерно 10 лет назад. Скажу как есть: изначально город мне не зашёл. Он был совсем не похож на уютную Рязань, где я вырос. Особенно усугубляли ситуацию осень(начало учебного года) и идущая за ней зима — с темнотой, серостью и вот этим всем.

В какой-то момент я смирился: ну, видимо, город такой. Сконцентрировался на учёбе, потом на работе.

Но со временем отношение менялось. Я люблю ходить пешком: иногда выхожу на пару станций раньше и иду остаток пути ногами, а иногда вообще обхожусь без транспорта — в разумных пределах, конечно. Так постепенно проникался городом и находил новые места.

Сейчас я уже совсем не могу надолго уехать: быстро начинаю скучать. Обожаю осень, весну и лето в Москве. Зиму, правда, так и не полюбил 😄

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

Яндекс решил организовать один из таких форматов — «Рекурсия по городу»: командное офлайн-приключение в формате CTF. Будет 35+ заданий по маршруту через точки, связанные с историей российской IT-индустрии: в том числе через территорию МГУ, центр фундаментальных исследований РАН и другие места.

Старт — в одной из моих любимых локаций: штаб-квартире Яндекса в «Красной Розе».

Если вам тоже интересны такие активности, переходите по ссылке и регайте команду