Матвей Клёнов | Frontend-разработчик

Очередной отзыв на курс «Архитектура Frontend'а для React-разработчиков» 🌟 В этом и прошлом отзыве нет упора на конкретные технологии – значит, подать информацию получилось верно. Мозг не «перещёлкнет», если вы просто будете вызывать методы библиотек. Это иллюзия развития, которая не даёт двигаться вперёд по-настоящему ❌ Курс помогает Frontend-разработчикам на React понять, что это всё лишь инструменты: какие-то лучше, какие-то хуже. Но писать или генерировать качественно можно в любой ситуации, если знать базу. Выход из этой иллюзии – большой шаг вперёд, вне зависимости от направления, в котором работаешь. Это переход со стадии «Применение» в стадию «Анализ», у кого-то даже в «Оценку» по таксономии Блума. Говорил об этом в видео «Frontend-разработчик в 2026: вырасти или застрять формашлёпом навсегда», там по таймкоду 5 минут про это. Если ты хочешь пробить плато развития, будучи React-разрабом, то ты можешь прочитать информацию в закрепе, либо нажать 🌟 сюда 🌟

🔤🔤🔤🔤 AI Agent на React за 15 минут: Agent Loop, Tools и AI SDK 🎞 В данном видео базово коснемся до "магии" инструментов, которыми сейчас пользуется вся планета: Claude Code, Opencode, Codex и т.д. Разберем такие темы как: ❤️Agent Loop ❤️Что такое AI SDK ❤️Что такое Tools ❤️Как реализовать простого AI агента на практике Ставьте лайки и пишите комменты, это помогает продвигать видео и мотивирует меня. Всем приятного просмотра! 🥳 Репозиторий с кодом видео 🔗

Лучший способ по-настоящему понять тему — объяснить её так, чтобы понял другой. В работе сейчас два видео: ❤️Гайд по базе Reatom'а ❤️Гайд по базе AI Engineering Хочу сфокусироваться на видосах, чтобы ребутнуть YouTube после паузы. Какие видео были бы вам интересны 🌟 Пиши в комментах 🔫

Курс «Архитектура Frontend’а для React-разработчиков» 🌟 Задача курса – стать швейцарским ножом по архитектуре для React-разработчиков. Для тех, кто хочет расти, но упёрся в потолок открытого доступа: либо новичковый контент про useState, либо толстая книга по архитектуре с примерами на Java. 20 часов контента по архитектуре, после которых вы: ❤ Перестанете мыслить только хуками и компонентами – начнёте мыслить модулями с чёткой ответственностью ❤ Научитесь адаптировать SOLID, Dependency Injection, Inversion of Control и паттерны проектирования под React ❤ Разберётесь в зоопарке React-экосистемы и поймёте, какие инструменты брать и какие у них трейдоффы ❤ Наконец разберётесь в стейт-менеджменте: не «Zustand, потому что популярный», а понимание, как меняется data-flow и архитектура на разных технологиях (основные в курсе – Reatom и MobX) ❤ Успокоетесь раз и навсегда со структурой папок: практика на FSD и FEOD ❤ Поймёте, как отделять бизнес-логику от UI и что это реально даёт Знания с курса можно адаптировать под любые направления. Есть интересно, то 🌟кликай сюда🌟 и присоединяйся

🔤🔤🔤🔤 MVVM для React: как разделить бизнес-логику и UI раз и навсегда 🎞 ❤️Теория MVVM ❤️Как влияет MVVM на скорость анализа кода ❤️Реализация MVVM на MobX ❤️Моё мнение по поводу MVVM vs Hooks (на хуках тоже можно норм писать) Репозиторий Miro-доска Трансляция про реактивность Всем приятного просмотра! 🥳

Анти-гайд по продаже стейт-менеджера *️⃣ Недавно смотрел конфу по Effector. Приложил скрины оттуда к видосу. До сих пор вижу как в 2026 году пытаются продать стейт-менеджеры не через их DX в сложных prod-кейсах (некоторые такого и не предоставляют на самом деле), а через сравнение с голым React'ом без инфраструктуры, очередной вкид про рендеры из-за React.Context и мемом, где 100 глобальных провайдеров оборачивают приложение. Хэйт хуков оправдан только в 1% приложений, где без хорошей реактивной системы ты просто сойдешь с ума. А хейт с аргументами в прикрепленном видео выглядит просто смешно. Надо быть прагматиком и действовать по ситуации. Вопрос лишь в том, понимаете вы ситуацию или нет. Скоро будет видео про MVVM, где поговорим об этом подробнее. Всем доброго вечера 🚬

Opencode Desktop + RTK CLI для сейва токенов Какое-то время пользовался Codex'ом и было норм, но ❤️После обновления ловил дефекты от которых горело одно место ❤️Мою карту "Плати по миру" реджектает OpenAi, а меня утруждает выкручиваться для простой оплаты сервиса. Почему они просто не хотят взять мои деньги? 😇 ❤️Постоянно выходят релизы новых моделей, но я не вижу кардинальной разницы уже давно Поэтому я просто вернулся на Opencode, но уже обновленный Desktop (скрин приложил) с подпиской на Opencode Go за 10 бачей, под мои задачи на данный момент хватает. Использую RTK CLI – CLI-прокси, который перехватывает shell-команды агента и сжимает их вывод перед тем, как он попадёт в контекст LLM. Делаем rtk init -g --opencode и переписываем скаченный плагин прям через Opencode как в этом Github Issue, чтобы он заработал для Desktop версии. Работаем, всем доброго дня 😤

Удобная работа с mermaid ❤️Просите Codex сделать визуализацию в mermaid формате нужных вам модулей и их связи ❤️Закидываете результат в Mermaid Live Editor и делаете тюнинг уже там Апдейты по жизни: ❤️Сдал диплом, скинув груз. Везде успевать на протяжении этих лет было оч тяжело, но мы справились. ❤️Доделываю последнюю часть курса, делаем фичу оформления документов со степпером, частый кейс для финтеха. Использую MobX и его экосистему. ❤️Много думал о развитии и уже есть понимание и трек дальнейших действий. Позже расскажу вам об этом, потому что будет влиять на канал. Спасибо, скоро буду 🌟

Дебютный отзыв на курс «Архитектура Frontend'а для React-разработчиков» ⭐️ Приятно услышать такой фидбек за честную работу. 🌟 Задача курса – стать швейцарским ножом по архитектуре для React-разработчиков. Для тех, кто хочет расти, но упёрся в потолок открытого доступа: либо новичковый контент про useState, либо толстая книга по архитектуре с примерами на Java. ❤️Смотришь на форму из 10 полей и не понимаешь, почему код выглядит так, будто это разработка ядерного реактора. ❤️Видишь Redux, MobX, Zustand, Reatom, Effector, Signals и не понимаешь, чем они различаются и как влияют на архитектуру всего приложения. Зоопарк, который на YouTube раскрывают на уровне доки или не раскрывают вообще. ❤️Слышал про DI, IoC, SOLID, но на практике не знаешь, как применять и зачем это вообще все? Какая польза? ❤️Застрял в чёрной коробке найма, где кроме Redux ничего не видел. Конечно, не видел, тех-лиду же важна «зрелость» и «популярность» библиотеки :) ❤️Хочешь работать в кайф, понимать какие инструменты позволяют это делать на самом деле и принимать архитектурные решения, которые влияют на весь проект. Если хоть один пункт про тебя, то тебе понравится. И всё это я делаю без переусложнений. Я не пытаюсь в курсе натянуть каждый паттерн из GoF на несуществующие примеры. Мы пишем приложение и из раза в раз улучшаем архитектуру, меняем стек, смотрим как это влияет на код. Ошибаемся, а потом исправляемся, чтобы понимать архитектуру, а не зубрить. Главное правило – простота. Simplicity is the key. Если где-то переусложняем, то я предупреждаю заранее и объясняю, зачем это нужно. Для образовательных целей это потребовалось, чтобы люди узнали, какие решения можно внедрить при разработке больших приложений. Теория в Excalidraw, практика уже в готовом коде. Вам не нужно будет повторять строчку за строчкой, я подробно объясняю уже написанный код после теории, экономя куча времени. Доступ ко всем урокам сразу. Никаких потоков и «открытий по расписанию». Смотри по порядку или сразу ту тему, которая нужна на работе прямо сейчас. Все вопросы во время обучения можно задать в чат курса. Есть интересно, то 🌟кликай сюда🌟 и присоединяйся В лс можно задать любые вопросы по программе.

Ответственность React – быть View-слоем Я думаю много раз видели огромные компоненты на 500+ строк, в которых намешана логика, UI, условный рендеринг, инфра и т.д Корень проблемы – размытые границы ответственности и не пониманием, что за что отвечает. В продакшене логики много, UI разрастается, условного рендеринга всё больше, и если четко не разделять ответственность, то компонент превращается в God Object, который нельзя ни прочитать, ни поддерживать. Ок, React отвечает только за View, все просто. Тогда почему я вижу компоненты, которые принимают по 15-30 пропсов? :) В данном видео расскажу вам про базовые принципы композиции компонентов: разделение layout логики от компонентов, паттерн slot, важность нейминга компонентов. Почему ваши React-компоненты невозможно читать 🌟 Почитайте ещё про renderProp, от слотов отличается возможностью получать данные компонента, в который мы этот render прокидываем. Стоит понимать, что эти рекомендации требуются для поддержки production-проектов. Всем приятного просмотра, буду рад комментам и лайкам🌟 И я изменил Excalidraw

Тут очень жесткий фундаментальный подгон по реактивности от Дениса и Дмитрия 🧩 web реактивность, все виды реактивности во frontend (react, vue, ...) feat: Денис izede Чернов Это одна из тех тем, которая может вытащить вас из непонимания зоопарка технологий и замотивирует вас как разраба. Мне кажется, что эта тема на равне с архитектурой пробивает плато «написал компонентик, useState сделал, пропсы прокинул» Вместо обнуления перед понедельником рекомендую вам к просмотру данную запись. И скоро будет новый видос на Youtube про то, какую ответственность React на себя должен брать при разработке больших prod-проектов. Всем добра 🥳

«Не пишу код руками» !== «Не думаю головой» Многие люди неправильно воспринимают фразу: «Не пишу код руками больше вообще» Под этим имеется в виду сам факт печати на клавиатуре, а не то, что Codex за вас всё делает. Исторически наша работа была устроена примерно как 80/20: ❤️80% – это рутинное исполнение задачи: написание бойлерплейта ручками на клавиатуре. ❤️20% – архитектурное мышление, проектирование, понимание точки A и точки B, как модули определенной ответственности будут взаимодействовать с другими модулями, подбор стека под задачу. И вот эти 20% всегда отличали avg кодера от реального инженера. Человека, который не просто дёргает API библиотек по доке, а для которого React – это просто инструмент для достижения конечного результата. Использование Codex'a и Claude Code не выдало людям эти 20%. Кто-то по-прежнему считает Zustand хай энд технологией и не понимает почему Redux – это прошлый век. Кто-то по-прежнему делает микрофронтенд-архитектуру для проекта из 10 страниц, абсолютно не понимая для чего они нужны на самом деле. Кто-то по-прежнему пишет логику в useEffect'ах. Кто-то делает AI-slop лендосы, которые вызывают не доверие к продуктам и специалистам. Убивают свои продажи, продукты, личный бренд. Кто-то воспринимает backend как чёрную коробку, которая отдаёт json'ы. И так далее. Хватит бояться фразы «Не пишу код руками». Осваивай эти 20%, а остальные 80 отдавай на ИИ-аппу, которую ты используешь. Не надо бороться с прогрессом, надо его правильно использовать. ИИ – это просто пинок для индустрии, которая спала многие годы. Компании нанимали сотни человек, когда хватило бы десяти. Люди не меняли направления по 10 лет, не пробовали новое, не углублялись в System Design. Они воспринимали свою работу как печать на клаве на определенной трендовой технологии и поэтому сейчас боятся за своё будущее, т.к понимают, что не могут закрыть те самые 20%. ИИ не заменит инженеров. Он заменит тех, кто инженером только притворялся. А что думаете вы🌟

Как сквозные модули решают свалку в папке common Огромный common – это база для больших проектов. Разработчики действуют так: если понимают, что что-то переиспользуется в двух-трех местах – значит кладём это в common. Размещение в глобальном common – знак для других, что можно тянуть этот модуль куда угодно. Строгость архитектуры пропадает. В FEOD есть такая концепция, как сквозной модуль, которая будет решать эту проблему. Если, конечно, разраб с головой. Представим, что у нас есть три модуля: npm, yarn и pnpm. И между ними есть общая логика. 🌟 До: src/ ├── common/ │ └── package-manager-core/ ← к общему имеет доступ весь проект │ ├── resolve-lockfile.ts │ ├── parse-manifest.ts │ └── index.ts └── modules/ ├── npm/ │ └── ... → импортит common/package-manager-core ├── yarn/ │ └── ... → импортит common/package-manager-core └── pnpm/ └── ... → импортит common/package-manager-core 🌟 После: src/ └── modules/ └── package-manager/ ← сквозной модуль (контейнер, без своей логики) ├── _/ ← private common: видят только соседи внутри │ ├── resolve-lockfile.ts │ ├── parse-manifest.ts │ └── index.ts ├── npm/ │ └── ... → импортит ../_ ├── yarn/ │ └── ... → импортит ../_ └── pnpm/ └── ... → импортит ../_ Мы внедряем сквозной модуль, задача которого сгруппировать наши 3 модуля и скрыть общую приватную логику только между теми модулями, где она используется. В «До» у нас область видимости – это весь проект. В «После» – ровно три модуля, где эта логика нужна. Так мы сохраняем строгость, защищая эту логику, а так же соблюдаем высокий cohesion. Такое простое действие значительно улучшает вашу архитектуру и структуру. Но учтите, что сквозной модуль правильно работает, когда модули – варианты одного домена. В нашем случае это пакетные менеджеры. А если какие-то модули просто делят логику, но имеют разные домены, то это будет некорректным решением. Не путайте переиспользуемость с принадлежностью. Всем доброй пятницы 🥳

Реактивность через Proxy🌟🌟🌟 Куча раз слышал на собеседованиях и просто в обсуждениях такую фразу: «React не реактивный, во Vue реактивность через Proxy» Proxy – это просто способ доступа до системы реактивности, а сама эта система (структура данных, способ обхода) у всех разнится. Например, в Preact Signals используется Linked List. Можете посмотреть в исходниках тип Node. И сам метод addDependency, который добавляет ноду в Linked List. Т.е сам по себе Proxy к реактивности никакого отношения не имеет. Это просто паттерн, который позволяет делать перехват вызова. У меня даже про него видос был давно : 🌟 Что такое Proxy в JavaScript. Реализация двустороннего связывания. Если в следующий раз услышите, что во Vue реактивность через Proxy, то корректируйте собеседуемого. Или даже собеседующего :) Вы так сделаете Frontend-мир чуть лучше. Всем доброго дня 🌟

Хочу обновить wallpaper канала, бустаните плз 🌟 https://t.me/boost/y0na24_dev

Архитектура vs Структура «О, ну проект на FSD, пацаны шарят» Возможно, пацаны ничего не шарят, а принимают все решения в проекте по принципу «подходит ли мой компонент по смыслу под слово entity», т.е совпадает ли он со словарём. Так максимум можно добиться норм структуры, но это не гарантия хорошей архитектуры. Чем же отличается структура от архитектуры❤️ Структура – это где файл физически лежит в дереве. Это твоя файловая система, не больше. Но кто-то недооценивает вклад структуры в архитектуру. Архитектура – это как течёт логика и какую ответственность берут на себя отдельные модули, и как эти модули дают доступ до своих методов другим. Как View, ViewModel и Model не знают (у кого-то знают) друг о друге. Это про связи, программные границы и направление зависимостей уже В КОДЕ, а не в сайдбаре вашего редактора. И тут бы я разбил сообщества на два лагеря: 🌟 «Можно в одном файле написать чистую архитектуру, структура – не так важно» Всегда удивлялся этому высказыванию, мне кажется, что это просто показуха дефолтная. Структура позволяет тебе не быть слепым котёнком, который ищет компоненты через Devtools'ы React'а и тот самый запрос на бэк за 10-15 кликов по "Go to Implementation". Я вам клянусь, когда работал в Сбере 😊 (без хейта, крупная компания – сто мелких компаний в одной, мне не повезло), то я узнал, где у нас слой запросов на второй месяц испыталки. Там были проблемы и с архитектурой, и структурой. DTO могла трансформироваться на разных слоях приложения, дополнятся клиенсткой логикой и было проще забить и просто работать с конкретной задачей/дефектом в узком месте, и уже по надобности искать иголку в стоге сена. Структура решает эти проблемы. Файлик api просто бы лежал в этом модуле. 🌟 FSD-культ Думают, что разложив файлы по «словарю» из документации – гарантия успеха. Слепое следование без понимание фундаментальных проблем, которые решаются. Кстати, из-за такого в плато развития и попадают. Формируется мышление «я вынес это сюда, потому что так написано в доке». А могло быть зрелое: «деление на features как на юзкейсы не решает проблем именно моего проекта. Поэтому мб будем класть бизнес-фичу в features, а рядом всё, что нужно для её реализации. Получим high cohesion внутри фичи и low coupling между ними. Будем находить нужное за секунды» 🌟 Хорошая архитектура без структуры не живёт (имхо) От структуры ты получаешь границы, входные точки и контроль доступа модулей. Что общее для всего проекта, что для трёх модулей, что для подмодулей внутри модуля. Без структуры ты это даже сформулировать не сможешь. Будешь мышкой по методам тыкать. От архитектуры ты получаешь простую поддержку и анализ КОДА (не сайдбар, еще раз). Твоя голова держит 2-3 уровня абстракции одновременно, дальше уже становится тяжело. Хорошая модульность и сборка зависимостей позволяет тебе держать их мало в голове: смотришь на React-компонент и думаешь только о композиции компонентов и как их друг в друга вложить так, чтобы декомпозиция была понятна; ушёл во ViewModel – переключил контекст, и теперь думаешь ТОЛЬКО о бизнес-логике, которая дёргает UI, низкоуровневый код тебя не волнует в этом слое; пошел в data-access уже смотреть детали запроса. Три отдельных куска пазла собрать воедино в разы легче. Но не переусложняйте раньше времени, размазанная не пойми зачем логика на 5 модулей тоже к хорошему не приведет. Ну и без базового DI ты на прямых импортах рано или поздно упрёшься в стену переиспользуемости, что критично для больших проектов. Структуру можно задокументировать, а в архитектуру уже надо уметь. Оч нравится подход в FEOD. Модульная задокументированная архитектура, которая сохраняет гибкость структуры. Фрактальность (её почему-то все бояться), сквозные модули, публичный API для скрытия логики, а не просто так. На это накладываешь архитектурные навыки, не переусложняешь лишний раз и выглядит как топ для разработки без боли. Нужна лишь практика, а дальше все пойдет. Буду писать финальную часть курса на нём, позже запишу ролик на YouTube 🥰 Спасибо и доброго дня🌟

Импортозамещение, которое мы заслужили Мне приятно видеть, что наши разработчики делают реально крутые Frontend-инструменты, которые решают проблемы. Три проекта, которые я использую сам и которые меняют то, как ты пишешь код. ✅Reactuse от Дмитрия Бабина 150+ кастомных хуков от Дмитрия и контрибьютеров. Каждый новый проект начинается с написания одних и тех же useDebounce, useLocalStorage, useClickOutside. Инфраструктурный код, который не должен жить в твоём репозитории. Подключаешь reactuse и забываешь об этом. Если хочешь, то можешь тянуть их себе в репо через CLI. Тулинг шикарный. ✅Reatom от Артёма Арутюняна Популярные решения для стейт-менеджмента либо примитивны как Zustand, либо неудобны как Redux. Это может вызвать впечатление, что на этом у нас всё и удобнее быть не может. Но это не так! Reatom – это реактивная система для написания бизнес-логики вне UI, сложность которой будет расти пропорционально сложности вашего приложения. (Это очень важное отличие от конкурентов) Есть свои формы и роутинг. Всем рекомендую попробовать данный инструмент, если ещё этого не сделали. ✅Экосистема для MobX от Сергея Волкова MobX очень хорош для работы с клиентским состоянием, но нет ничего для работы с серверным состоянием, формами и роутингом. Mobx Tanstack Query – обёртка над Tanstack Query Core, чтобы использовать мощь Tanstack ВНЕ React. Ты избавишься от боли синхронизации состояния, потому что сможешь делать запросы прямо из Mobx-стора. Тебе больше не нужен useQuery. Твой UI будет чистым, потому что бизнес-логика в хуках больше не живёт. MobX-react-hook-form – обертка над createFormControl, которая синхронизирует его с Mobx. MobX-route - легковесный типизированный роутер для Mobx. Интересный факт. Сергей мой сосед почти, живем в 150 метрах. Мир тесен, как говорится. И это не просто пост поддержки. Я сам пользуюсь этими инструментами. Они включены в мой курс по архитектуре.

DI – это не про подмену для тестов В прошлом посте я сказал, что «подмена для тестов» – это моя любимая фраза от разработчиков, когда спрашиваешь про DI. Сегодня раскрываю, что DI делает на самом деле. Если коротко, DI делает две вещи, про которые редко говорят: 🔴Вынуждает тебя собирать зависимости в конкретном месте. Так называемый Composition Root. 🔴Заставляет писать модульный код. Иначе тебе просто нечего будет собирать. Разберу обе мысли на конкретной фиче. Представь: тебе прилетает задача реализовать форму регистрации документа. Многошаговая форма со степпером: 4 шага, на каждом свои поля, между шагами есть валидация, отправка на бэк, бизнес-логика проверки наличия черновиков и т.д Просто стоит понимать, что эта фича – это не просто один компонент. Это какой-нибудь StepperProvider, который рисует компонент шага исходя из currentStep. И компонентов будет достаточно много, один шаг – отдельный модуль со своей формой, логикой, композицией ui-компонентов. Назовём фичу DocumentRegistration. Как пишет 90% разработчиков (я серьезно, каждый рабочий проект, который я анализирую): Каждый шаг формы сам ❌напрямую❌ импортирует то, что ему нужно. Step1 импортирует API-клиент, Step2 импортирует валидатор, Step3 импортирует репозиторий. И произошла ситуация, что теперь DocumentRegistration-процесс еще нужно внедрять и для VIP-клиентов. В итоге в коде я могу увидеть часто вот такую ситуацию: export function Step4Submit({ formData }: Props) { const { user } = useUser(); const handleSubmit = async () => { if (user.isVIP) { await vipApi.submitDocument(formData, { priority: 'high', notifyManager: true, }); } else { await standardApi.submitDocument(formData); } }; return <Button onClick={handleSubmit}>Отправить</Button>; } И так на каждом шаге. Анализ сложнее, подмена сложнее, больше тратишь сил и времени (и денег, соответсвенно) А можно было внедрить Composition Root 🚶‍♂️ Composition Root – это единственное место в приложении (или в модуле/фиче), где собираются и связываются конкретные реализации зависимостей. Всё остальное приложение работает с интерфейсами и не знает, кто их реализует. Это «грязное» место по дизайну. Здесь разрешено знать про конкретные реализации, писать тернарники, читать конфиги. А в коде процесса мы уже работаем с интерфейсом. 🔫 Пример псевода-кода – preview поста 🔫 Если у тебя есть Composition Root, значит тебе вообще есть что собирать. У тебя нет God Object'ов, где у тебя живет и состояние, и запросы, и куча всего. У тебя отдельные модули со своей ответственностью. Это и есть скрытая суперсила DI. Не «подмена для тестов», а архитектурная гигиена, к которой DI принуждает тебя как побочный эффект. А как дела с этим в твоём проекте? Всем доброго вечера, друзья 🥳

Архитектура – это то, что невозможно просто загуглить Я провожу собеседования на позиции мидл/сеньор и каждый раз вижу одно и то же. Человек чётко рассказывает определение SOLID. Произносит слова «инверсия зависимостей», «принцип единственной ответственности», «открыт для расширения, закрыт для модификации». Всё по учебнику, здорово и классно. Но в современном мире можно получить доступ к любой информации за 5 секунд и обычный пересказ лично меня уже не удивляет. Я прошу человека объяснить как адаптировать эти принципы под реальный Frontend и какую ценность это даёт. Какая настоящая польза. Обычно «громкая» тишина секунд на 5, после чего абстракции про «гибкость и поддерживаемость», за которыми ничего не стоит. Это миддлы и сеньоры. Люди с 4-7 годами опыта в крупных компаниях. Зарплаты от 250к. И они не могут объяснить, зачем существует то, что они «знают». Эта закономерность в какой-то момент меня поразила. Почему так? 🔴Найм сломан Система грейдов в IT работает примерно никак. Собеседования проверяют умение пересказать статью с Хабра, а не умение думать. Человек выучил определения SOLID, прошёл скрининг по чек-листу и получил ярлык «миддл». Прошло два года и получил ярлык «сеньор». Зарплата выросла, а навыков так же нет. Это называется Bozo Explosion – термин из Apple. A-игроки нанимают A-игроков. B-игроки нанимают C, чтобы на их фоне выглядеть умнее. C нанимают D. Через пару итераций компания собеседует и продвигает посредственностей, которые собеседуют и продвигают других посредственностей. Это и есть рынок, на котором ты сейчас работаешь. 🔴В архитектуре нет универсальных рецептов Даже если ты прочитал «Чистую архитектуру», DDD и паттерны GoF, то этого недостаточно. Эти книги писались про энтерпрайз-бэкенд: про Java, про многослойные серверные приложения и огромные монолиты. Их идеи фундаментальны и применимы везде, но никто за тебя их не адаптирует под React, где половина библиотек прибита гвоздями к жизненному циклу, а каждый второй разработчик пишет бизнес-логику прямо в JSX. В React даже где ты держишь стейт меняет архитектуру приложения до неузнаваемости. Стейт внутри React (хуки, Context, Tanstack Query) и стейт снаружи React (Reatom, Effector, MobX) – это два разных мира. И если ты учишь не архитектурный подход, а синтаксис конкретной библиотеки, то ты вообще не растёшь. Ты просто меняешь одну зависимость на другую и думаешь, что прокачался. Возвращаемся к тем самым ребятам с собеседований. Они читали книги. Они знают синтаксис библиотек. Но архитектурно не выросли. Почему? Потому что между «знать» и «уметь» огромная пропасть. Вот как её заполнить: ✅Практика Использовать рабочий код как полигон. Зрительно проектировать архитектурные границы и видеть, как они улучшили бы систему. Напиши один и тот же пет-проект на Reactuse, Redux и MobX, например. Не просто подёргать API, а сравнить подходы: привязка к жизненному циклу React, централизованный store, бизнес-логика вне React. ✅Рефлексия После каждого архитектурного решения спрашивать себя: «А моя система стала проще или я просто паттерн ради паттерна внедрил?» «Окей, я вынес логику вне React, какие бенефиты в поддержке проекта я получил?» «Хорошо, я внедрил DI, а что он мне реально дал, кроме обычной "подмены для тестов"?» (это вообще моя «любимая» фраза. Если бы DI был просто подменой для тестов, то про него не писали бы в каждой книге по архитектуре) Поэтому когда разработчик говорит «я знаю SOLID», то это мало что значит. Значимый ответ на вопрос звучал бы так: «Я применил DIP на проекте X, потому что нужно было подменить источник данных. Получилось вот так, заплатил вот этим, в следующий раз сделал бы по-другому, потому что…». Это разница между тем, кто читал, и тем, кто думал. Короче, архитектуру надо выстрадать. Всем спасибо!