Руслан Куянец | Reactify

👩‍💻 Эволюция Frontend Архитектуры: от Монолита до Microfrontends (Monorepo, Multirepo) В этом видео разберём эволюцию больших frontend-систем: Monolith → Modular Monolith → Monorepo → Multirepo → Microfrontends. На примере роста большой платформы посмотрим: — почему один frontend начинает не справляться с ростом команды; — зачем переходят от монолитного приложения к модульной архитектуре; — чем отличаются Monorepo и Multirepo; — когда появляются отдельные приложения и бизнес-контуры; зачем нужны Microfrontends; — как независимые команды получают свои релизы, CI/CD и жизненный цикл. Разберём: — Frontend Architecture — Microfrontend Architecture — Monorepo vs Multirepo — Modular Monolith — Frontend Scaling — Large Scale Frontend Applications Видео будет полезно frontend-разработчикам, архитекторам и техническим лидерам, которые строят масштабируемые веб-приложения. Видео уже на канале Reactify! Я не оставляю ссылку, так как видео лучше продвигается, если заходить на него напрямую с YouTube. Это помогает улучшить его рейтинг и увеличить шансы на органическое продвижение. 🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube

Скоро возвращение на YouTube 💪🏼 1. Разбор самого душного собеса: V8, Hidden classes, JIT, TS, Garbage Collector и другие необычные темы на собесе 🤯 2. Архитектура Frontend: Monorepo, Multirepo, Microfrontends, Monoliths Схема эволюция на примере больших компаний Видео в монтаже 💪 Так же много сценариев написал, буду контент машину запускать 🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube

👩‍💻 CI/CD для фронтендера часть 3 В прошлый раз мы остановились на моменте, когда Pull Request прошел ревью, получил аппрув и попал в ветку develop. Теперь начинается самое интересное — что происходит после merge и как код оказывается в Kubernetes. Разберем путь от merge до деплоя. Итак, разработчик сделал merge: feature/YH-1422 → develop С этого момента обычно запускается новый workflow. Первый этап — сборка. CI/CD система берет свежий код из ветки develop и выполняет примерно такие шаги: — скачивает репозиторий; — устанавливает зависимости; — собирает приложение; — запускает необходимые проверки; — создает артефакты сборки. Для фронтенда результатом обычно будет набор статических файлов: dist/ ├── index.html ├── assets/ ├── javascript bundles └── styles Но часто в современных проектах дальше появляется Docker. Вместо того чтобы просто отправлять файлы на сервер, приложение упаковывается в Docker image. Например: код приложения ↓ npm install ↓ npm run build ↓ Docker image ↓ Container Registry Docker image — это готовая версия приложения вместе с необходимым окружением. Например: frontend-app:1.25.0 Эта версия уже сохранена в Registry, откуда ее сможет забрать Kubernetes. Следующий этап — Kubernetes. Kubernetes сам по себе не знает, какую версию приложения нужно запускать. Ему нужно описать желаемое состояние: — какой image использовать; — сколько запустить копий приложения; — какие ресурсы выделить; — какие настройки применить. Обычно это описывается через Kubernetes manifests или Helm charts. Например: frontend: image: frontend-app:1.25.0 replicas: 3 То есть мы говорим Kubernetes: "Мне нужно 3 экземпляра фронтенда версии 1.25.0" И Kubernetes делает все необходимое: — скачивает Docker image; — создает контейнеры; — запускает приложение; — проверяет, что оно работает; — заменяет старую версию новой. В GitOps подходе мы обычно не отправляем команды напрямую в Kubernetes. Вместо этого есть отдельный репозиторий с описанием состояния инфраструктуры. Например: application-config frontend: image: frontend-app:1.25.0 Изменили версию в Git → система увидела изменение → обновила Kubernetes. И здесь появляется ArgoCD. ArgoCD постоянно сравнивает: что написано в Git vs что реально запущено в Kubernetes. Если есть различия — он выполняет синхронизацию. Например: В Git: frontend-app:1.25.0 В Kubernetes: frontend-app:1.24.0 ArgoCD увидит расхождение и обновит приложение. В итоге весь путь выглядит примерно так: Merge в develop ↓ CI/CD workflow ↓ Build приложения ↓ Docker image ↓ Container Registry ↓ Обновление конфигурации в Git ↓ ArgoCD ↓ Kubernetes ↓ Новое приложение работает И вот этот процесс обычно скрыт от фронтендера. Разработчик сделал merge — через несколько минут новая версия уже доступна на стенде. Но за этим стоят несколько систем, которые работают вместе: Git → CI/CD → Docker → Registry → GitOps → ArgoCD → Kubernetes Первые 4 шага можно изучить в нашем репозитории: https://github.com/YeaHubTeam/yeahub-platform/blob/main/Dockerfile В следующей части можно разобрать уже сам Kubernetes: что такое Pod, Deployment, Service, Ingress и как вообще фронтенд приложение живет внутри кластера 🙂 🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube

💼 Персонализированная подготовка Весь июль тестировали Календарь собеседований и внедряли новый подход к подготовке. Раньше мы в основном готовили ученика до выхода на рынок, а дальше уже подключались точечно, если нужен был мок. И этого подхода в целом хватало. Каждый ученик до выхода на рынок проходил 5–13 экзаменов по всем темам (экзамен = мок с ментором), потом ещё 2+ дополнительных мока и прожарки. Плюс были рандомные моки с другими ребятами примерно 2 раза в неделю. Этого было достаточно, чтобы получать офферы. Но рынок стал тяжелее. Конкуренция выросла, компании стали сложнее отбирать кандидатов, и сейчас нужно выжимать максимум из каждого шанса. Поэтому мы поменяли подход. Есть собеседование в Т-Банк и там лайвкодинг? Сделаем мок лайвкодинга именно под формат Т-Банка. Финальный этап в Сбере? Сделаем часовой мок по софтам и разбору опыта, чтобы максимально повысить шанс пройти. То есть после выхода на рынок ученик теперь имеет возможность делать практически неограниченное количество моков с ментором по необходимости, пока ищет работу. Это и есть персонализированная подготовка. И всё это стало возможным благодаря трекингу собеседований через Календарь. Но моки — это только часть. Календарь даёт ещё несколько сильных возможностей. 🚂 Паровозы собеседований Например, Ваня прошёл собеседование в Авито. Через неделю Петя идёт туда же — Ваня может передать ему вопросы, рассказать про этапы и помочь подготовиться осмысленно. Раньше такие связи часто терялись. Теперь мы специально их создаём. 📚 Материалы и реальные вопросы Мы подключили помощника, у которого есть доступ к куче источникам с записями собеседований, слитыми вопросами, задачами и закрытыми базами. Когда ученик добавляет собеседование в календарь — мы можем искать актуальные материалы именно под эту компанию и этот этап. Давать это ученику. 🤝 Рефералы Ещё один важный эффект — растёт база контактов. Например, ученик прошёл собеседование в Сбер, но понял, что ему не подходит офисный формат. Он с большей вероятностью сможет порекомендовать другого ученика, которому такой формат подходит. Получается система, где ученики помогают друг другу получать больше возможностей. За июль Календарь уже показал хороший результат: — 8 рефералок ученик → ученик — 11 паровозов по собеседованиям — 20 собеседований, где удалось найти вопросы и записи, которые совпали с реальными этапами примерно на 90% — дополнительные моки для подготовки к алгоритмам и финальным этапам Это только первый месяц. Чем больше данных собираем, тем точнее понимаем, где можно помочь, какие компании сейчас нанимают и как увеличить шанс получить оффер. Мы не ждем хороший рынок 🚀 Мы побеждаем на любом 💪

Для меня это был шок. Код был слабый, базовой логики и понимания разработки почти не было. Но человек получал 250 тысяч рублей в месяц. И знаете что? Он молодец. Он смог попасть в систему, пройти фильтры и получить результат. Возможно, ему вообще не интересно, что кто-то считает его путь неправильным. Типа: «Хэй, я получаю 250к, а вы тут сидите и год ищете работу, зато говорите про честность». Это было бы не очень красиво с его стороны. Но доля правды в этом есть. Потому что рынок в итоге вознаграждает не самых правильных. Он вознаграждает тех, кто смог адаптироваться под его правила. И, наверное, главный вопрос не в том, правильно это или нет. А в том: Нужно ли быть лучшим разработчиком или нужно уметь доказать рынку, что ты им являешься?

🤬 Дилемма IT-рынка Дилемма разработчика: быть хорошим инженером или хорошим кандидатом? Под комментариями к видео-прожарке люди разделились на два лагеря. https://youtu.be/a43a-SCCHLg Одни говорят: «Как можно не знать такие вопросы? Это же база». Вторые говорят: «А зачем вообще задавать такие вопросы? Они ничего не показывают». При этом и среди первых, и среди вторых были люди как с опытом, так и без него. И вот тут начинается интересная дилемма. Когда еще не было всей этой рыночной истерии, к собеседованиям относились проще. Опытные ребята, работающие в топовых компаниях, на собесах могли просто поговорить за жизнь — и их брали в Альфу, ВК, Сбер, Ростелеком и другие компании. Не было жесткой проверки знаний. Алгоритмы, задачки и вопросы с собеседований считались отдельным навыком, который хороший разработчик знать не обязан. Время шло. Записей собеседований на YouTube стало в сотни раз больше. Списки вопросов, подборки задач, сервисы подготовки — все стало доступно. Подготовиться стало намного легче. Но вместе с этим поменялись и правила игры. Сейчас уже недостаточно просто хорошо работать. Если ты приходишь на собеседование неподготовленным, то можешь проиграть человеку с меньшим опытом, который просто хорошо натренировал формат собеседования. Готовиться к собеседованиям нужно. Это буквально часть профессии и реалии текущего рынка. Улучшать резюме, правильно себя презентовать, иногда чуть подкручивать формулировки — это тоже часть игры. Потому что какой смысл быть добрым, честным и иметь реальные навыки, если ты просто не проходишь первый фильтр и месяцами сидишь без работы? Особенно сейчас, когда самый жесткий рынок находится в диапазоне 1-3 лет опыта. Но даже если человек условно добавит себе год и попадет в фильтр 3-6 лет, он все равно будет внизу выдачи. HH ранжирует кандидатов: сначала идут люди с опытом 5+ лет, потом уже 3-4 года. Когда я делал эксперимент с вакансией, в топ-50 выдачи было около 80% людей с опытом 5 лет и больше. Хотя на саму вакансию откликались разные люди. Кандидатов с 3-4 годами было тоже много, просто они находились ниже. Кстати, проводя собеседования опытным ребятам, которые приходят за помощью с поиском работы, я часто вижу пробелы в базе. Многие опытные разработчики не знают нормально про классы и прототипы. Ошибаются в задачах на this и Event Loop. Не умеют решать алгоритмические задачи. Кто-то не может нормально отрефакторить React-компонент — хотя это один из популярных типов лайвкодинга. А иногда проблемы вообще с базой: человек не помнит, что делают логические операторы, какая разница между функциями, как работают фундаментальные вещи языка. И вот тут возникает вопрос: а что тогда вообще считать опытом? Количество лет в компании? Количество написанных строк кода? Умение решать реальные бизнес-задачи? Или способность пройти проверку на рынке? Правильно говорят, что собеседования — это отдельный навык. Если опытный разработчик не готовится, его может обойти менее опытный специалист, который просто лучше подготовился и умеет играть по новым правилам. Еще часто говорят: «Опытный разработчик не значит хороший разработчик». И я с этим согласен. Я регулярно встречаю людей с большим опытом, которые пишут код, который сложно поддерживать, сложно читать и сложно масштабировать. Мне кажется, что в ближайшие годы с развитием нейросетей разница между просто опытным разработчиком и специалистом, который умеет думать, писать хороший код и правильно использовать AI-инструменты, будет только расти. Мой пик менторства и помощи с трудоустройством новичкам пришелся на 2025 год. И честно, я иногда не понимаю, как некоторые ребята раньше без нейронок умудрялись накручивать опыт и работать в компаниях. Только если с помощью сильного наставника на испытательном сроке. Но как-то же люди справлялись. И за это им большое уважение. Помню, в начале 2024 года я помогал человеку, который накрутил себе 3 года опыта и попал в Сбер. Он обратился за помесячной помощью на испытательном сроке.

👩‍💻 Прожарка собеса на Frontend Разработчика https://youtu.be/a43a-SCCHLg Когда мне предложили провести прожарку собеса, я сначала хотел взять какой-нибудь идеальный кейс. Тот самый собес, где ученик приходит, отвечает на все вопросы, закрывает все этапы и забирает оффер. Казалось бы, для ментора это самый красивый пример. Но когда я начал готовить сценарий, понял — разбирать там особо нечего. В YouTube и так много собесов, а сама идея прожарки как раз в другом: найти ошибки, разобрать их и понять, что можно было сделать лучше. Поэтому решил взять первый серьезный собес ученика в Big Tech. Ученик учился 8 месяцев: прошел весь стек, закрыл все основные темы и сдал 13 экзаменов. После этапа теории еще 2-3 месяца ушли на практику, стажировку, создание резюме, проработку опыта и подготовку самопрезентации. И вот здесь есть важный момент. Когда ты проходишь большой объем теории, а потом несколько месяцев фокусируешься на практике и подготовке выхода на рынок, часть тем уже не ощущается так свежо, как сразу после изучения. Поэтому перед собесами всегда важно возвращаться к базе и держать знания в тонусе. Сейчас рынок тяжелый, поэтому стратегия была не уходить в бесконечную подготовку, а быстрее выйти на рынок: начать откликаться, получать реальные собеседования и параллельно повторять уже изученный материал. Плюс нужно учитывать временной лаг: часто после отклика проходит 2-4 недели, пока HR дойдет до резюме и начнется активная коммуникация с компаниями. Но хорошее позиционирование сработало быстрее, чем ожидали. Уже в первые дни начали приходить сообщения от компаний, а технические этапы начали назначаться буквально через пару дней. Среди них были крупные компании: Альфа, Сбер, VK, Яндекс, X5 и другие. Поэтому я и решил прожарить именно первый его собес в Big Tech: сделать работу над ошибками, вместе с Антоном разобрать моменты, дать советы и навалить базы. 📚 Материалы для подготовки к собеседованиям Что важно понять из этой истории: — Даже на сложном рынке правильная подготовка и позиционирование могут привести к большому количеству возможностей. — Даже если ты прошел все темы и сдал десятки проверок, нельзя терять тонус. Базу нужно постоянно поддерживать. — Любой собес — это не приговор, а обратная связь. Он показывает, что нужно докрутить перед следующими этапами. — Не стоит быть вечным учеником. Конечно, если бы подготовка продолжилась еще 1-2 месяца, знаний было бы еще больше. Но было бы столько собесов? А кто его знает, рынок меняется быстро. Спустя месяц после этого собеса ученик получил оффер в финтех-компанию с хорошей зарплатой — 260к. Он не сдался, продолжил искать, сделал работу над ошибками и выбрал правильную стратегию выхода на рынок. 🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube

Про ИИ истерию. Полностью согласен. Наконец-то все собрали в одно видео 😁 https://youtu.be/t_Z-KkJamSg?si=bBuScU9n-NHN2fQr

Немного о честности и доверии https://t.me/mentor_reactify/389

🖥 CI/CD для фронтендера часть 2 Недавно мы разобрались с основными понятиями: что такое CI/CD, GitOps, Docker, Kubernetes и зачем вообще фронтендеру понимать эти вещи. Теперь давайте посмотрим, как выглядит путь обычной задачи в реальном проекте. Представим, что разработчик берет задачу YH-1422. Под нее создается отдельная ветка, например: feature/YH-1422 В этой ветке пишется код, фиксируются изменения через commit, после чего они отправляются в удаленный репозиторий: commit → push → Pull Request Еще до отправки кода могут запускаться локальные проверки. Обычно это Husky, линтеры, форматирование или тесты. Их задача — поймать простые ошибки еще до того, как изменения попадут в репозиторий. Это еще не CI, а скорее локальная автоматизация, которая помогает разработчику. После создания Pull Request уже подключается настоящий CI. В зависимости от проекта автоматически могут запускаться: — установка зависимостей; — линтеры; — тесты; — сборка приложения; — дополнительные проверки безопасности или качества кода. Если хотя бы одна проверка не пройдет, замержить изменения, скорее всего, не получится. Часто CI интегрирован с таск-трекером. Например, после создания Pull Request задача автоматически переходит в статус In Review, а после merge — в Done. Разработчику уже не нужно менять статусы вручную. На некоторых проектах для каждого Pull Request автоматически создается отдельное тестовое окружение (Preview Environment). То есть изменения из ветки feature/YH-1422 разворачиваются по отдельному адресу, и тестировщики или заказчик могут проверить новую функциональность, не затрагивая общий стенд разработки. После того как код прошел ревью, получил аппрув и успешно протестирован, Pull Request мержится в ветку develop. И вот здесь для большинства проектов заканчивается CI и начинается CD. Дальше коду предстоит пройти еще несколько этапов: — сборка приложения; — создание Docker-образа; — публикация образа в Registry; — обновление приложения в Kubernetes; — синхронизация через GitOps (например, с помощью ArgoCD). Именно на этом этапе код превращается в работающее приложение, которое увидят пользователи. Но это уже отдельная большая тема. В следующем посте разберем весь путь от merge до деплоя в Kubernetes и посмотрим, что происходит "под капотом". 🙂 🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube