FRONTEND ROADMAP

Этот пост будет актуален для тех, кто только начинает свою карьеру во фронтенде.

Очень много вопросов в личку с просьбами подсказать, где лучше всего изучать фронтенд и как понять, что уже можно начинать искать работу. В интернете очень много курсов и материалов на любой вкус и цвет - и, пожалуй, даже слишком много, новички теряются во всем этом многообразии. Я составила подробный роадмап по необходимым технологиям, необходимым для начинающего специалиста. На мой взгляд, это самый минимум, который необходим, чтобы начать работать. Ссылка: https://devmargooo.notion.site/1-Junior-1cda1781152280a493f0ffae70992f09.

В этом роадмапе есть платные (но очень дешевые - 590р/месяц) материалы, в которых, на мой взгляд, хорошо структурирована информация и ученики легко обучаются по этим материалам. Для тех, кто не хочет платить, я указала бесплатные аналоги (но в них информация структурирована и “разжевана” чуть хуже).

Кратно приведу список моих любимых ресурсов для новичков:

1️⃣ HTML и CSS: https://htmlacademy.ru/. Любимая школа обучения верстки, обычно я даю ссылку на нее своим ученикам и они пропадают на несколько недель, обучаясь самостоятельно и в целом не сталкиваясь ни с какими проблемами. Уровень усвоения материала - близкий к 100%. Платные материалы именно с этого ресурса я включила в свой роадмап, потому что незнание этих тем (и последующее разжевывание их вам ментором), на мой личный взгляд, обойдется вам гораздо дороже.

2️⃣ Javascript: https://learn.javascript.ru/. Абсолютно бесплатный учебник по javascript, который содержит ВСЕ необходимые для трудоустройства и дальнейшей работы темы.

3️⃣ Typescript: https://code-basics.com/ru/languages/typescript. Этот курс, на мой взгляд, лучший из бесплатных. На мой взгляд, он довольно бегло проходится по основным темам, многие из которых можно раскрыть еще на пару-тройку модулей в курсе. Но для новичка этот курс - то, что нужно! Здесь все самое основное и не перегружено подробностями. Для того, чтобы работать миддлом, информации здесь слишком мало :)

4️⃣ React: https://ru.hexlet.io/courses/js-react. Курс по подписке на хекслете, которая стоит 3900р/месяц. На мой взгляд, это вполне справедливая цена за хорошо разжеванный и структурированный материал :) Для тех, кто не хочет платить, есть бесплатные материалы в моем роадмапе - список всех нужных тем и ссылки.

5️⃣ Redux: https://code.mu/ru/javascript/framework/react/book/redux/. Это достаточно простая технология, ее вполне можно изучить по бесплатному материалу на code.mu. Ему не хватает интерактивности, но на мой взгляд, такую простую технологию можно изучить и без интерактивных заданий. Более интерактивный и разжеванный курс есть на хекслете за 3900/месяц: https://ru.hexlet.io/courses/js-redux-toolkit

P.S. Роадмап junior -> middle в разработке

#роадмап

Подборка лучших постов айти блогов за месяц

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

Пост Артёма зацепил меня позицией, близкой к моей - я не стремлюсь поймать work/life balance, я стремлюсь поймать shit/awesome balance :D и работа для меня чаще всего попадает в awesome. У Нади в посте интересный технический контент, мне вообще нравятся Next и Nuxt за то, что они позволяют делать интересные вещи. Делюсь всей подборкой:

🪲 У меня самый популярный контент за месяц - серия постов про дебаг: Как новичку дебажить? Часть 1.

👉 Гриша продолжает обозревать фичи Svelte. Публикация уже на канале.

🧠 Наташа помогает отслеживать баги в мышлении, она коуч ICF и QA-инженер: На чём, на самом деле, держится ваша мотивация?

💡 Тимлид Артём рассказал, как у него стёрлась грань между жизнью и работой.

🔥 Коуч Анна делится важностью проявления агрессии в карьере в голосовом.

🐱 Надя снова ломает границы фронтенда! Рассказывает, как настроить телеграм-бота для уведомлений с сайта без бэкенда.

🤵 Разработчик Саша думает о пользователях и рассказывает, как соблюдать UX-законы при разработке фронтенда.

🍔 Раушан ударился в кулинарию: тудушка бутера, алгоритм приготовления суши.

😡 Счастливый тимлид походу перегрелся и бомбит то на кандидатов, то на формы регистрации.

Первая годная статья про оценку задач, которую я встретила на просторах интернета. Метод выглядит как рабочий. Сама я пользуюсь схожим способом - оценку через разработку POC (буду писать об этом подробнее)

https://habr.com/ru/companies/ru_mts/articles/898644/

#оценказадач

Выводим многострочный текст

В javascript многострочный текст можно вывести при помощи шаблонных литералов (строка с косыми кавычками). Но есть лайфхак, который позволяет сделать то же самое другим путем: сделать массив строк, а затем объединить их в одну при помощи «\n»:

const arr = [‘one’, ‘two’, ‘three’];
const str = arr.join(‘\n’);

Это удобнее тем, что теперь к каждой строке можно применить map и как-нибудь преобразовать строки. Например, выполнить toUpperCase или заключить каждую строку в тег <b>. Это может быть полезно для создания кейсов в сторибуке.

Как новичку дебажить? Часть 3.

Выше (по хештегу #дебаг) я писала о том, что при дебаге нам нужно отследить путь данных. Хочу отдельно пояснить, что именно мы отслеживаем.

Любая программа представляет из себя совокупность данных, которые каким-то образом изменяются на протяжении своей “жизни” в программе. Проще говоря, результат преобразований можно представить как y = f(x), где х - входные данные, f - преобразующая функция, y - результат. На примере: допустим, у вас есть функция multipleByTwo, который умножает число на 2. Вы вводите 3 и получаете 8 (а должны были получить 6). В этом примере: y (результат) равен 8 и получен он был путем применения функции multipleByTwo к входным данным (то есть к числу 3).

Получаем:

multipleByTwo(x) = 8

Поскольку результат (восьмерка) является результатом воздействия функции multipleByTwo на x, то ошибка может быть в двух местах:

1. В самой функции (multipleByTwo)
2. Во входных данных (x)

В первом случае это означает, что алгоритм функции неверно написан (например, там какой-то код, отличный от return x * 2). Во втором случае это означает, что мы передали неверные данные (например, промазали по клавиатуре и случайно тыкнули 4 вместо 3).

Теперь разберем на реальном примере. Допустим, ваше приложение получает с бекенда какие-то данные для отображения в селекте. Вы тыкаете в ваш селект и видите, что никаких опций не отобразилось. Смотрите в код и видите это:

<Select options={mapData(dataFromApi)} />

Таким образом, ошибка может быть в двух местах:

1. В функции, которая мапит данные (ошибка в алгоритме)
2. В данных, которые пришли с бекенда (например, запрос свалился и ничего не пришло)

Для дебага надо проверить оба этих случая.

В реальных фронтенд приложениях данные проходят большой путь от получения их с сервера до вывода на экран. Поэтому реальное уравнение - это не y = f(x), а y = foo(bar(someMethod(a, b, c), d), e). То есть получается довольно длинная цепочка преобразований от начала и до конца. Проследить путь данных - это по всей цепочке выяснить, какие данные (a, b, c, d, e) используются, корректные ли они, а также какие алгоритмы (foo, bar, someMethod) к ним применяются и найти ошибку в этой цепочке.

#дебаг

Накрутка опыта, инфляция и конкуренция

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

В среднем, накрутчики-фронтендеры крутят себе 3-4 года опыта. Ваши резюме попадают с ними в одну кучу и поэтому ваши шансы быть приглашенными на собеседование уменьшаются пропорционально количеству резюме с заявленными 3-4 годами опыта. При ближайшем рассмотрении оказывается, что ваши шансы быть приглашенными на собеседование даже ниже, чем у накрутчиков - их резюме выглядит привлекательнее, потому что придумать всегда можно более классные задачи и результаты, чем сделать и решить на самом деле. Я видела несколько сотен накрученных резюме и их большая часть поразила меня своими выдающимися достижениями. Мое резюме - специалиста с реальным опытом 8+ лет - содержит гораздо более скромный список достижений, чем придуманные достижения накрутчиков. В реальной жизни мы ограничены дедлайнами, необходимостью делать рутинные таски на благо бизнеса, а также ограничениями нашей системы, в то время как придуманные достижения не ограничены ничем, кроме полета фантазии. Суммарно эти два фактора: высокая конкуренция среди специалистов с заявленными опытом 3-4 года и бОльшая привлекательность накрученных резюме снижают ваши шансы попасть на собеседование практически до нуля.

Многие помнят, что популяризаторы накрутки опыта советовали крутить “годик”. Откуда же взялись 3-4 года опыта, спросите вы? Дело в том, что корень проблемы никогда не было в “автофильтрах”, как нам это утверждают популяризаторы накрутки. Корень проблемы всегда был и будет в высокой конкуренции. Пару лет назад высокая конкуренция была только среди джунов: в постковидные времена мы получили большое количество выпускников курсов, которые вышли на рынок, где для них не оказалось такого количества вакантных мест. Накрутка опыта помогала не “пройти автофильтры”, а попасть в ту часть воронки, где конкуренция была ниже - то есть на уровень специалистов с опытом от года. Но как только все массово стали крутить себе годик, то что произошло? Теперь конкуренция перешла на этот уровень. Стало слишком много специалистов с годом опыта работы. Чтобы выделиться среди них, приходилось крутить уже по два года, затем по три, и вот сейчас мы застряли на средней отметке в 4 года накрученного опыта. Так мы пришли к инфляции опыта: чем больше людей крутит себе N лет, тем большему количеству людей приходится крутить себе N+K лет, чтобы не оказаться в той куче, где конкуренция высока, и перейти на уровень, где конкуренции мало или почти нет. Инфляция опыта коснулась и работодателей: теперь эйчары просто смотрят резюме от 5 лет опыта, понимая, что из них реального опыта - пара лет. Чем больше накрутчиков на рынке и чем больше они крутят, тем хуже приходится каждому отдельному накрутчику.

Что же со всем с этим делать? Я хочу обратить ваше внимание на то, что реальной причиной сложности поиска работы всегда были не “автофильтры” (они лишь являются следствием большего количества кандидатов), а конкуренция. Годы опыта и достижения в резюме - основной, но не единственный способ победить в этой конкуренции. Вспомните про альтернативные джоб бордам методы, а именно: рефералки, личный бренд, нетворкинг, участие в хакатонах, выступления на митапах, интересные проекты на гитхабе и тд. Очень многие команды столкнулись с такой проблемой найма, как несоответствие кандидатов заявленным в резюме скиллам, что существенно затягивает процесс поиска работы. Личное знакомство с таким лидом, который ищет специалиста - это путевка на собеседование, минуя все автофильтры. Будьте заметными, вносите вклад в профессиональное сообщество, рекламируйте себя как специалиста - это существенно повышает ваши шансы быть замеченным и нанятым.

#поискработы

Владилен Минин в своем телеграмм канале опубликовал пост с ссылкой на вакансию стажера, в которой кандидату предлагают работать за… опыт и сертификат о прохождении стажировки. И пока в комментариях обсуждают звериный оскал капитализма и беспредельную наглость работодателей, я хочу обратить ваше внимание вот на что: бесплатные стажировки в том или ином виде существуют в большинстве профессий. Например, мастера маникюра после обучения делают маникюр бесплатно на моделях, парикмахеры - стригут бесплатно и тд. В телеграмме и Вконтакте существуют много групп, где можно записаться на бесплатный маникюр или стрижку к вот такому вот стажеру. Ваша покорная слуга является большой любительницей посещать бесплатные фотосессии у новичков-фотографов и потом выкладывать красивые фотографии в соцсети… впрочем, я отвлеклась. Стажировка (практическая работа над реальным или близком к реальному проектом) - это неизбежная часть любого обучения. Если вы программист - в вашей карьере так или иначе будет первый для вас проект, и именно на нем вы будете учиться работать. Для вас существует несколько вариантов:

1️⃣ Бесплатная стажировка в айти компании - похожая на ту, что в вакансии выше.

2️⃣ Стажировка на реальном проекте у ментора / на курсах. В этом варианте вам придется платить за то, что вам все объясняют и делают ревью вашего кода.

3️⃣Самостоятельная стажировка: сделать несколько проектов, залить их в гитхаб, опыт работы над ними подробно описать в резюме, приложив ссылки (к слову, именно этот вариант я и рекомендовала большинству новичков года 2-3 назад - до эпохи массовой накрутки)

4️⃣ Оплачивая стажировка от компании. Обычно стажеру платят 80-120к.

5️⃣ Устроиться на миддла (например, накрутив опыт) и дальше “стажироваться” за счет работодателя, набивая стажерские шишки и наступая на стажерские грабли за зарплату миддла.

Теперь, когда мы выяснили, что стажироваться (т.е. набивать шишки на первом в карьере проекте) так или иначе придется, я хочу привести несколько аргументов того, что первый вариант имеет ряд плюсов, которые делают его довольно привлекательным:

1️⃣ Вы качаете хард скиллы. Это очень важно, потому что у большинства новичков объективно не хватает хард скиллов. Хард скиллы вам нужны, чтобы: а) проходить собеседования без стресса и получать офферы б) успешно справляться с рабочими тасками, не сталкиваясь со стрессом, не перерабатывая. Чем выше хард скиллы, тем ниже стресс, который вы получаете от работы, тем больше работы вы можете сделать, тем больше вы можете заработать.

2️⃣ Вы качаете софт скиллы. Большинство новичков не умеет работать с традиционно принятыми в айти компаниях инструментами управления проектов (например, jira, confluence) и теряется, когда нужно “прогнать задачу по статусам”, а еще не знает, как правильно доносить свои мысли до коллег. Стажировка поможет вам научиться.

3️⃣ Вы можете работать неполный день. Это очень полезно, если у вы свитчер и переучиваетесь с другой профессии: тогда вы сможете плавно войти в новую для себя профессию, при этом сохраняя старую работу и свой привычный доход. Вы реально можете усидеть на двух стульях! В то же время, если вы выбираете вариант №5 (устроиться сразу на миддла с накруткой опыта), вы рискуете не потянуть, быть уволенным и остаться без дохода вообще - ведь с предыдущей неайтишной работы вы уже уволились. Также вариант с неполным рабочим днем идеально подходит для студентов. (продолжение в следующем посте)

(начало в предыдущем посте) Я сама на старте своей карьеры проходила бесплатные курсы-стажировку Focus Start от компании ЦФТ - и там меня научили всему, что мне потребовалось на старте: верстке, написанию кода на js, работе с фреймворком (первый ангуляр… как давно это было). После этой стажировки я очень легко смогла найти работу, потому что у меня были соответствующие хард и софт скиллы, я понимала, как работают процессы в айти компаниях, и понимала, как делать реальные проекты. Поэтому я в большинстве случаев положительно отношусь к бесплатным стажировкам - при условии, что на них действительно учат, а не сгружают на стажера тупую работу типа “поменять строку в коде”. Если вы попали на стажировку и вы чувствуете, что ничему там не учитесь - уходите немедленно.

Почему я не боюсь, что если люди будут соглашаться на бесплатную стажировку, то работодатели воспримут это как то, что теперь можно не платить программистам? Потому что бесплатная стажировка актуально только для тех, кто прошел обучение, но у кого пока нет практического опыта работы с реальным проектом. Если у человека есть опыт работы с реальным проектом хотя бы 2-3 месяца, бесплатная стажировка для него неактуальна от слова совсем. Бесплатными стажерами потребности бизнеса не закроешь, поэтому для программистов, которые желают быть оплаченными, найдется много работы 😊

И последнее. Играет ли какую-нибудь роль сертификат? Конечно нет 😊 Такой сертификат не является документом государственного образца, чтобы значить хоть что-то. Впрочем, в айти и на дипломы ВУЗов обращают не так много внимания - главное скиллы кандидата. Поэтому, если решите пойти на стажировку, внимательно рефлексируйте, действительно ли вы закрываете ваши потребности в том, чтобы попрактиковаться на реальном боевом проекте и отточить свои навыки? Если нет - смело уходите с такой стажировки.

✨ На грядущем PiterJS для вас выступит Маргарита Лукина с докладом:

Эволюция SSR в React приложениях

Появление серверных компонентов внесло путаницу в React сообществе.
🔸Чем серверные компоненты отличаются от клиентских?
🔸В чем преимущества тех и других?
🔸Как они работают под капотом?
Доклад ответит на этот и другие вопросы

Важно! На территорию университета можно пройти только при подтверждении личности! Регистрируйтесь под своим именем и фамилией и возьмите на мероприятие паспорт! 🔥

✨ Регистрируйтесь под своим именем и фамилией, если допустили ошибку => отмените регистрацию и сделайте корректную.

До встречи 😊

Композитная структура фронтенд проекта

Многие мои знакомые в курсе, что я недолюбливаю FSD. В целом, мне не импонируют любые достаточно плоские методологии структурирования проектов - как раз из-за своей плоскости. “Плоским” я называю структуру, в которой у нас существуют директории, предполагающие наличие большого количества содержимого. Например, папочка components, в которой может быть 100 и более компонентов. В таком количестве очень сложно найти то, что тебе нужно. Сегодня поделюсь рецептом структуры, которой пользуюсь я сама. Дисклеймер: возможно, он уже был где-то и кем-то описан - но я про это не в курсе 😊 Я называю такую структуру композитной, потому что она напоминает мне паттерн “компоновщик” (Composite). Итак:

1️⃣ На верхнем уровне я располагаю основные директории - app (главный файл, конфиги приложения), pages (страницы), components (компоненты), helpers (хелперы), store (стор). Важно: в components мы кладем не любые компоненты, а только глобальные - то есть такие, которые используются повсюду в нашем приложении. Аналогично используем хелперы и стор - только для глобальных сущностей.

2️⃣ В pages создаем страницы.

3️⃣ В страницах повторяем верхнюю структуру: components, helpers, store. Сразу уточню, что папочки добавляем по мере создания файликов - пустые папки нам не нужны :) Но на этом уровне кладем сюда только те компоненты/хелперы/стор, которые используются на этой странице. То есть в pages/Home/components может лежать, например, компонент Hero - если он используется на главной странице и больше нигде.

4️⃣ Внутри компонентов структура может снова повторяться: например, компонент Hero может содержать дочерние компоненты, а также может содержать хелперы.

5️⃣ Для каждой страницы действуем по аналогичному принципу.

Таким образом, общий принцип: кладем сущность туда, где она непосредственно используется. Если сущность используется в нескольких местах, кладем на общий уровень для мест использования. На примере компонентов:

🔵 Компонент Card используется только на странице Catalog - кладем компонент в src/pages/Catalog/components/Card

🔵 Компонент CardHeader используется только внутри компонента Card - кладем компонент в src/pages/Catalog/components/Card/components/CardHeader

🔵 Компонент Button используется везде - кладем в src/components.

#архитектура

В наше время только ленивый не делает гипотез о том, как ИИ изменит нашу профессию. Я не ленивая, поэтому впишусь в общий тренд и тоже выскажу свою гипотезу относительно того, какие навыки фронтенд разработчиков будут востребованы через 5 лет:

1️⃣ DDD

ИИ умеет писать код, но ему необходим контекст. DDD - отличный способ донести контекст вашего проекта до машины.

2️⃣ Архитектура на уровне кода (SOLID, GRASP, etc)

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

3️⃣ Продвинутая верстка

Если вы когда-нибудь пробовали десятком промптов уточнить чату гпт картинку, которую нужно сгенерировать, вы поймете, в чем проблема. Объяснить человеку, какую картинку хочется получить, все еще намного проще. То же самое касается анимаций. Кроме того, продвинутые навыки верстки вам потребуются, если вы захотите сделать что-нибудь эдакое, что редко встречается и, соответственно, ИИ не имел возможности обучиться делать это на большом количестве случаев.

В последнее время очень много вопросов в личку про оформление резюме. Только сегодня мне с этим вопросом написали трое - а ведь люди должны в это время жевать шашлыки 😊 В этом посте поделюсь с вами подробным рецептом приготовления хорошего резюме. Дисклеймер: информация актуальна для РФ.

0️⃣ Предварительные условия

Помните, что серебряной пули не существует. Единственный способ составить действительно идеальное резюме - это соврать в нем. Реальный человеческий опыт всегда имеет какие-то слабые места, несоответствие портрету “идеального кандидата”. Чем лучше ваш реальный опыт, тем лучше будет ваше резюме (при условии, что вы его не выдумываете). Если какой-то ментор обещает вам составить 100% рабочее резюме и при этом ничего в нем не придумывать - он вас обманывает.

Общие рекомендации

1️⃣ Помните, что вы составляете резюме в первую очередь для ATS и только во вторую очередь для HR и технических специалистов

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

2️⃣ Не указывайте свой возраст

Компании часто имеют представление о том, какого возраста должен быть их идеальный кандидат, и по этой причине фильтруют как слишком “молодых”, так и слишком “возрастных”. По ТК РФ работодатель не имеет права дискриминировать вас на основании возраста - с вашей стороны вы можете не давать ему лишнего соблазна этого сделать, просто убрав возраст из резюме. На hh убирается в разделе “Профиль -> Основная информация”

3️⃣ Укажите свой telegram в контактах

Эйчары часто используют телеграмм для связи с кандидатами. Укажите свой телеграмм в контактах. Зайдите “Резюме -> Контакты” и добавьте свой телеграмм в раздел с телефоном или “другой сайт”.

Сделайте ваше резюме понятным

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


4️⃣ Описывайте процесс работы, а не результат

Разработчики очень часто описывают в резюме не результаты, а обязанности, и, кроме того, делают это размыто. Пример: “реализовывал фронтенд приложения с нуля для заказчиков”. Что это были за проекты, что они умели делать? Например, я ищу разработчика, чтобы он сделал мне личный кабинет пользователя - как по такому описанию я должна понять, справитесь вы с задачей или нет? Акцент должен быть на результат и пользу ваших действий. Пишите результаты своей работы так, чтобы они были понятны даже человеку, который не знаком с вашей компанией, вашими проектами и вообще в первый раз о них слышит. Например: “разработал модуль корзины, интегрировал его с бекендом, добавил аналитику действий пользователя”. Благодаря такому описанию работодатель сможет понять, какие задачи вы можете решать. Вы можете проверить ваше резюме, дав его прочитать другу- если он поймет, чем вы занимались, то опыт работы описан верно.

5️⃣ Для каждого проекта укажите стек, с которым вы работали

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

6️⃣ Укажите сферу деятельности компаний, в которых вы работали

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

7️⃣ Для каждого проекта кратко укажите размер команды

Например: “2 бекенд разработчика, 3 фронтенд разработчика, 2 qa”

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

#резюме

Жизнь - это постоянный выбор из довольно большого числа альтернатив. В работе (и ее поиске) нам обычно важно получить наибольший профит с наименьшими затратами. Исходя из этого, мы пытаемся понять, выгодно ли нам, скажем, проводить время на литкоде или красиво оформлять гитхаб или эта работа не принесет нам достаточного профита, чтобы тратить на это свое ценное время. Я придерживаюсь точки зрения, что важно учитывать не только прямую, но и косвенную пользу наших действий.

В комментариях к предыдущему посту мы обсуждали, стоит ли заниматься “причесыванием” проектов на гитхабе для поиска работы. Комментаторы справедливо заметили, что очень небольшой процент работодателей вообще смотрит на гитхаб, а те, кто смотрит, делают это бегло. Означает ли это, что разработкой проектов на гитхаб невыгодно заниматься? Отнюдь. Помимо прямой пользы (то есть повышения привлекательности для того небольшого процента работодателей, которые таки гитхаб смотрят) вы получаете очень много косвенной пользы. Смотрите сами:

1️⃣ Когда вы разрабатываете проекты для своего гитхаба, вы качаете скиллы. Я думаю, нет необходимости объяснять, почему скиллы имеют ГЛАВНОЕ значение в вашей карьере. Вы получаете навыки, которые помогут вам: 1. Пройти собеседование 2. Решать ваши рабочие задачи 3. Получать меньше негативных комментариев на ревью 4. Отстаивать свою точку зрения.

2️⃣Когда вы “причесываете” проекты (выстраиваете архитектуру, рефакторите) вы тоже качаете скиллы. В коммерческой разработке вам тоже придется постоянно “причесывать” ваш код перед ревью, так что вы не просто тратите время впустую, а получаете очень ценный навык. Кроме того, это - опыт, про который можно поговорить на собеседовании.

3️⃣ И как вишенку на торте, вы получаете дополнительные очки в глазах того процента работодателей, которые на этот гитхаб таки смотрят.

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

Пользователи часто (и небезосновательно) упрекают нас в том, что наши приложения тормозят. Фронтенд приложения не React могут тормозить из-за избыточных ререндеров. Написала небольшую заметку о том, как отслеживать ререндеры React компонентов с помощью девтулзов:

https://devmargooo.notion.site/React-devtools-1e9a1781152280e69e1cc6f84fa20f9d

#перфоманс

Ошибка, из-за которой вы не проходите собеседование

Частая ошибка на собеседовании/скрининге - кандидату непонятен вопрос и он не пытается его уточнить, а отвечает, что не знает, или отвечает не то. Например, спрашивают про опыт работы с css библиотеками, кандидат отвечает, что не работал, а на самом деле имелись ввиду css фреймворки (bootstap, etc), с которыми кандидат работал. Или, например, спрашивают про css фреймворки, кандидат называет бутстрап, а на самом деле интервьюер хотел услышать БЭМ (css методология). Поэтому, если вам задают вопрос, на который вы не знаете ответа и при этом вы миддл и выше - попробуйте для начала уточнить, о чем идет речь. К сожалению, в айти часто происходит путаница терминов (чего только стоят баталии по поводу именования какой-нибудь вещи “библиотекой” или “фреймворком”!). Скорее всего, вы знаете ответ на этот вопрос, а если даже точно на этот вопрос не знаете, знаете что-то аналогичное. Уточнение, что вы говорите об одном и том же - важный софт скилл, потому что, к сожалению, в айти командах довольно часто происходят ошибки из-за банальных недопониманий.

Например, вас спрашивают принципы работы redux, а вы работали только с mobx. Не спешите отвечать, что вы не знаете, как работает redux: расскажите про ваш опыт с mobx, как вы его использовали, какая у него архитектура и юзкейсы. В айти СЛИШКОМ МНОГО технологий и вы точно не сможете поработать со всеми. Профессионализм программиста определяется тем, насколько хорошо он умеет разбираться с новыми вещами на основании опыта работы с похожими. Поэтому на вопрос о какой-то вещи, которую вы не знаете, вполне валидно рассказать о вещи, которую вы знаете: интервьюер поймет, что вы сможете быстро разобраться с тем, что нужно будет ему. А если вы ответите “не знаю”, тогда, к сожалению, интервьюер не сможет этого понять.

#собеседования

Неочевидный тренд в найме в 2025 году

В конце 2024 и 2025 году я стала замечать новый тренд в найме программистов: компании стали обращать много внимания на опыт с аналогичной доменной областью. Проще говоря, маркетплейсы отдают предпочтение кандидатам с опытом работы в маркетплейсах, видеостриминговые платформы - кандидатам с опытом работы в аналогичных платформах, и т.д. Это довольно логично, однако многие из нас могут вспомнить, как несколько лет назад компании при найме обращали главное внимание на стек, а опыт с аналогичной доменной областью был делом десятым. Считалось, что если кандидат владеет стеком, то сможет быстро “переучиться” работе с новой доменной областью. Я думаю, что тренд на внимание к опыту работы со схожим доменом связан со следующими факторами:

1️⃣ Больше программистов на рынке => есть из кого выбрать

2️⃣ Распространение ИИ => теперь гораздо важнее понимать, ЧТО ты хочешь запрограммировать, а не КАК

Что это значит для кандидатов? Тренд подсказывает нам, что лучше выделить в своем резюме, чтобы повысить шансы на трудоустройство:

1️⃣ Делайте акцент на профите от вашей работы, а не на деталях реализации (на том, ЧТО сделали, а не КАК)

2️⃣ Откликаясь на вакансию, подсветите в резюме релевантные вакансии задачи. Откликаетесь в маркетплейс? Напишите про страницы каталогов, которые вы делали, с фильтрами и сортировками, и тд.

#резюме

🍝 Готовим React Context

React Context - полноценный инструмент для хранения и чтения глобального состояния. Обычно в контексте хранится набор значений и их методов. Однако он имеет проблему с производительностью: когда меняется любое поле в контексте, все подписчики контекста ререндерятся. Так происходит потому, что объект контекста сравнивается по ссылке, и если меняется поле в контексте, то потребитель получает новую ссылку на контекст, что приводит к ререндеру - даже в том случае, если поле, которое поменялось, не используется в этом компоненте вообще.

✍️ Несколько рецептов, которые помогут вам использовать удобно контекст и снизить проблемы с производительностью:

1️⃣ Разделяйте один контекст на несколько маленьких. Например, вместо одного AppContext с множеством свойств создайте отдельные контексты UserContext, ThemeContext и т.д. В таком случае при изменении свойства в UserContext будут перерендерены только те подписчики, которые подписаны на UserContext, а те, которые подписаны на ThemeContext, не будут - ведь он не изменился.

2️⃣ Кешируйте через useCallback и useMemo значения, которые возвращаете из контекста - в таком случае в компоненте-потребителе вы сможете безопасно передавать их в дочерние компоненты, не опасаясь, что каждое изменение контектста приведет к замене ссылки и перерендеру дочерних компонентов.

3️⃣ Создавайте хук для взаимодействия с контекстом. Вместо того, чтобы в каждом компоненте писать const mydata = useContext(MyContext), сделайте такой простой хук:

export const useMyContext = (): MyContextProps => {
    const context = useContext(MyContext);
    if (!context) {
        throw new Error(‘MyContext not found :(’);
    }
    return context;
};

#react

Лексическое окружение

Начну серию постов, связанную с замыканиями, утечками памяти через замыкания, stale state и stale props в React. В Javascript есть три основные концепции, связанные с замыканиями:

🔹 Lexical environment
🔹 Environment record
🔹 Execution context

Сегодня поговорим о первой из них, а именно - о лексическом окружении.

🔶 Лексическое окружение - это структура, которая определяет, какие идентификаторы (т.е. переменные) доступны в данном фрагменте кода. Создается в момент вызова. Фрагментами кода, которые создают новое лексическое окружение, являются:

🔹 Js файлы. Когда мы запускаем код из js файла, создается глобальное лексическое окружение, и переменные из него будут доступны в любом месте в этом файле
🔹Функции. Вызов функции создает новое лексическое окружение для нее, повторный вызов создаст новое лексическое окружение
🔹Блок кода (то, что внутри {}). Когда интерпретатор доходит до блока кода, он создает новое лексическое окружение, в котором могут находиться переменные, объявленные через let и const.

Каждое лексическое окружение имеет ссылку на внешнее лексическое окружение. Для глобального лексического окружения ссылка на внешнее будет равна null.

На картинке выше вы можете увидеть код и схематичное изображение его лексического окружения. Лексическое окружение foo содержит в себе идентификатор c и ссылку на внешнее лексическое окружение, которое является глобальным. Глобальное лексическое окружение содержит в себе два идентификатора, а его ссылка на внешнее лексическое окружение равна null.

#javascript #замыкание #lexical_environment

⚡️ Что такое замыкание и как оно приводит к утечкам памяти

В прошлый раз мы с вами говорили о лексическом окружении и причинах его создания, а сегодня поговорим о замыканиях. Термином “замыкание” в javascript обозначает функцию и ее лексическое окружение. Как вы помните, лексическое окружение в javascript содержит в себе ссылку на внешнее лексическое окружение - таким образом, все внешние лексические окружения для функции будут доступны ей через цепочку ссылок.

Что происходит с лексическим окружением функции после того, как она завершила свою работу? Довольно часто оно больше не нужно и уничтожается, однако бывает и иначе. Рассмотрим пример:

function makeCounter() {
    let count = 0;
    const increment = () => count++;
    return increment;
}
let counter = makeCounter();
counter();
counter();

Функция makeCounter завершила свою работу, однако лексическое окружение, которое она создала - с идентификатором count в нем - осталось в памяти. Почему так? Потому что лексическое окружение функции makeCounter - внешнее для лексического окружения функции increment, которая в нем создается. Когда мы вернули из makeCounter функцию increment, прицепом к ней мы вернули все ее лексическое окружение. Поскольку на это лексическое окружение ссылается increment (ниже counter - это две переменных указывают на одну область памяти), то лексическое окружение вместе с переменной count надежно зависло в памяти до тех пор, пока counter остается ссылочно доступен.

В данном случае makeCounter у нас “зависло” совсем маленькое лексическое окружение с переменной count - однако бывают и гораздо более серьезные утечки памяти, связанные с замыканиями. Такая ситуация происходит, если “зависшее” лексическое окружение занимает много места в памяти и/или ссылается на другие “тяжелые” лексические окружения. Вот здесь я писала об одной из таких утечек в Promise.race, а в следующий раз поговорим с вами о том, как “зависшее” лексическое окружение приводит к ситуациям, которые мы называем stale props и stale state.

#замыкание #javascript