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

Я Тёма. В профессиональной разработке около 6-7 лет. + какое-то количество лет разработка была хобби.

Сейчас я фронтенд разработчик Кинопоиска(Яндекс). Ранее трудился в Tinkoff и других компаниях. Успел побывать на различных проектах. На больших/маленьких, для внутреннего использования и для большой внешней аудитории, начинал свои стартапы и тд.

Как хобби занимаюсь обучением.
Преподаю в ШРИ Яндекса:
- Лекция по базовому Реакту
- Лекция по продвинотому Реакту и еще одна
Преподаю в learn.javanoscript.ru:
- Расширенный курс по Реакт
- Интенсив по TS

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

Надеюсь вам будет полезно и интересно. Все ваши предложения, пожелания, мысли можете смело писать в комменты к постам, на все отвечаю лично я, буду очень рад)

Локальный стейт в React
#Фронтенд

Доброе утро, работяги!

Локальный стейт в React компонентах используется очень часто. Обычно для этого используют хук useState(но есть и другие). На первый взгляд нет ничего проще локального стейта, но это не так. Это первый пост из серии о локальном состоянии в реакте. В этой серии разберем о том как готовить стейт правильно, различные нюансы, хаки и тд.

Где располагать стейт?(part1)
#Фронтенд

Ответ на этот вопрос очень простой - где нужен стейт, там и располагаем. И на этом можно было бы закончить пост, но нет. Если все так просто, то откуда появляются God components?

God Component(компонент бога, богоподобный компонент) - компонент, который умеет слишком много, содержит слишком много состояний, слишком много логики. Является антипаттерном.

God component к сожалению не редкость. Я сам присутствовал на пришествии нескольких таких божеств, а парочку по неопытности склепал сам. Чем он плох?

1. Понять что он делает без бутылки бывает очень сложно. Следовательно поддержка -
2. Из-за переплетения интриг логики посадить там баг очень просто. Надежность -
3. Описать его тестами очень сложно, тк вы просто не можете сформулировать что он делает. Обычно если вы не можете описать тестами ваш компонент, то это звоночек, что он он протух и воняет. Надежность —
4. Добавить туда новую функциональность очень сложно, нет тестов(либо они хуже самого компонента), код не самодокументируемый, кейсов использования очень много(логики ведь куча). Поддержка —
Продолжать этот список можно очень долго, но я думаю смысл вы поняли. Эта штука гниет и в будущем может потащить за собой весь проект. Как с ними бороться поговорим отдельно. Сейчас вернемся к стейту.

Где располагать стейт?(part 2)
#Фронтенд

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

Для себя я вывел простое правило. Располагай стейт максимально близко к месту использования. Компонент со стейтом следует делать максимально компактным, в идеале стейт, необходимая логика и логика его отображения. Если ваш стейт потребовался другому компоненту, то тут стоит задуматься о вынесении этого стейта на уровень выше, но не раньше. Старайтесь избегать локального стейта, который прикидывается в кучу компонентов, тк в этой ситуации он уже не выглядит локальным, подумайте о вынесении его в полноценный стейт менеджер(redux и др) или контекст(как правильно готовить контексты обсудим отдельно).

Всем продуктивной недели!

Метрики
#Продуктивность

Доброе утро, работяги!

Метрики? Продуктивность? Точно?
На самом деле я не ошибся, это действительно пост про продуктивность.

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

С недавних пор я рассматриваю внедрение «советов по продуктивности» как оптимизацию. А без чего оптимизация не имеет смысла? Без метрик! Метрик до оптимизации и после. Сравнив их мы можем понять, работает ли та или иная техника для нас(а большинство советов по продуктивности не универсальны) или нет. И только сравнение метрик может сказать нам стоит ли внедрять ее на постоянной основе или лучше закончить эксперимент.
Поэтому перед каждым новым внедрением я выбираю метрику, определяю желаемый показатель(цель), ставлю сроки(без них никак, будет отдельный пост про них) и начинаю эксперимент. По окончанию срока сравниваю метрики и принимаю решение о внедрении или о продлении экспа(иногда результат хороший, но цель слишком амбициозная, либо сроки слишком оптимистичные).

Как выбрать метрики? Что такое хорошие метрики? Какие метрики являются опережающими? Об этом поговорим в одном из следующих постов серии.

Всем продуктивного вторника!

Грядут перемены
#Фронтенд

Сложно представить современный веб интерфейс без анимаций. И я сейчас не говорю о свистелках-перделках, а я о самых простых, заскейлить, прозрачность добавить, цвет поменять и тд. Но почему-то некоторые анимации работают плавно, а некоторые нет. Хм… очень странно, ведь для анимации изменений всех этих свойств мы используем один инструмент - transition.

Секрет заключается в том, что анимация разных свойств имеет разную производительность, разное количество слоев затрагивается. Анимировать opacity или анимировать height, совсем разные вещи.

Как решать эту проблему? Использовать transform. Да в некоторых ситуациях это поможет, но transform покроет не все кейсы.

Решение есть - will-change. Используя его вы сообщаете браузеру о том, что свойство будет меняться. Браузер подготовится заранее и ваша анимация будет гладкой.

Но! Нельзя навешивать will-change на все без разбора, тк слишком обильное использование может ухудшить производительность.

Как тогда быть? Где мера?

Есть один лайфхак- вешать это свойство динамически. Но! Если вы повесите его при наведении на элемент, на котором при наведении нужна анимация эффекта не будет. А вот если повесить его на элемент тогда, когда вы заходите мышкой в блок, в котором этот элемент расположен, то будет лучше. Важно, контейнер не должен 1 в 1 повторять размеры элемента, иначе нет смысла, в этом случае стоит найти блок побольше. Таким образом браузер будет готовиться к изменению свойства только тогда, когда пользователь будет близок к этому элементу, а не находится совсем в другой части страницы.

Такой подход позволит не просадить ваш интерфейс, все будет работать плавно.

Дисциплина и разработка
#Продуктивность

Почти всю мою жизнь меня потряхивало от слова дисциплина. Я всегда считал, что все это херня, а я творец, поэтому нахер все эти правила, костюмы с рубашками, галстуки, распорядки дня и прочее. Мне повезло, я просто любил учиться и у меня это получалось. В противном случае хз что было бы…

Когда я начал заниматься разработкой ничего не изменилось. Я влюбился в это дело и окунулся в него с головой. Чувствовать себя творцом и презирать дисциплину я не переставал.

Увлеченность это очень круто, горящие глаза и вот это все. Но если плюсом к этому нет дисциплины, то такой сотрудник может стать опасным.

Почему?

Стабильность. В большинстве своем такие люди нестабильны. Сегодня они работают 24/7 тк задача очень интересная, они узнают новое. Но когда наступает рутина все меняется. Они не предсказуемы. Прогнозировать работу такого перца сложно. В любой момент он может выгореть и отвалиться, подвести всю команду. И хуже всего если такой человек считает, что все ок.

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

С ростом сложности задач, количеством обязанностей начали появляться проблемы. Небольшие, но они начались. Они были не очень критичные, но потом понеслось. Ковиды, удаленки, череда событий из жизни, потом ремонт, потом 24февраля и вся эта вереница событий стала мощным испытанием моей продуктивности.

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

И ныть можно долго. Но однажды я решил пойти в зал, тренажерку. Если вы тренировались, то знаете, что без режима сна, режима питания и регулярных тренировок результат будет 0. Я начал постепенно соблюдать режим сна, питания, ходить в зал. Я начал видеть результаты. И вот тут меня осенило.

Дисциплина

Я ходил раньше в зал, но результата не было. А тут поперло. Я просто соблюдал режим, все.

И я решил применить дисциплину к работе. Важно отметить, если это ваша первая тренировка, то вы не ломитесь к 100кг штанге. Так и тут я не стал этого делать. Поставил себе маленькую цель. Целую неделю, каждый день писать код 6 интервалов по 25мин.

Важно! Я говорю про сконцентрированную работу. 25мин только код, никаких отвлечений.

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

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

Потом я добавил интервалы обучения. Начал с одного в день, постепенно ращу их.

Я стараюсь не делать больше интервалов, чем я запланировал. Иногда срываюсь, но стараюсь.

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

Как трекер я использую приложение Forest, но подойдет даже таймер. Интервалы по 25 мин и 5 мин отдых. Считаю успешными интервалы только сконцентрированной работы, без заглядывания в мессенджеры, отвлечений и тп.

В итоге дисциплина меня вытащила. Нет, галстук я не ношу, но стабильнее стал) Поэтому не бойтесь дисциплины, а используйте как инструмент.

Стоит ли возвращаться в офис?
#ПростоМысли

Привет, работяги!

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

Немного вводной, я не претендую на объективность, тк это мой личный канал и посты пишу я сам, поэтому обойтись без отпечатка моего мнения, предпочтений и тп сложно. Я люблю работать из офиса и с радостью вернулся после ковидных ограничений. Но в удаленке я вижу определенные плюсы, периодически использую. Текущий мой режим работы скорее гибридный, обычно 1-2 дня из дома и остальные в офисе.

Начнём с +:
1. Дисциплина. Походы в офис это некий ритуал. Каждый день в одно время. Приучает к порядку.

2. Из первого плюса вытекает следующий. Нормализация режима дня. Если ты ходишь на работу в одно время каждый день, то скорее всего и вставать ты должен в одно время, следовательно и ложиться тоже. А это уже режим сна.

3. Дорога до офиса помогает настроиться на рабочий лад. Для меня это что-то медитативное.

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

5. Чтение. Больше всего книг я прочитал, когда жил в Зеленограде и ездил до Москвы на электричке. С приходом удаленки я начал читать меньше. Вся суть в том, что прям качественно работать в дороге сложно. Да, можно сделать что-то мелкое, но назвать это прям работой сложно. А вот читать да, особенно хорошо читать на апайде или подобном устройстве, сразу можно сделать заметки.

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

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

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

2. Невозможность сконцентрироваться в опенспейсе. Такая проблема действительно есть. Не везде и не все знакомы с культурой работы в офисе, не все умеют ценить чужое внимание и время. На удаленке ты десять раз подумаешь, стоит ли звонить, писать. А когда человек сидит в метре от тебя, то отвлечь его очень просто, многие этим злоупотребляют. Иногда, когда нужно сделать особенно заковырестую задачку, а концентрация разлетается по всему офису, я специально остаюсь дома и полностью погружаюсь в нее.

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

Продолжение…
Повторюсь, я не претендую на полную объективность. Со многими проблемами я не сталкивался, поэтому их здесь нет. Кто-то уходит в офис от домашней суеты, кто-то слишком интроверт и не выходит из дома, кто-то любит море и не хочет в город, а у кого-то летом огород. Все это тоже аргументы, но не мои, поэтому приводить их здесь я не буду. НО! Буду очень рад, если вы в комментах накидаете свои мысли по этому вопросу, очень интересно узнать как вы используете удаленку/гибриды и тд.

#Анонсы
Еще у меня для вас две новости:

1. В эту суботу пройдет мой интенсив по тайпскрипту. Если вы давно хотели его изучить, либо просто освежить знания, то буду рад вас видеть. По промокоду TEMA_TS будет скидка 10%. Залетайте https://learn.javanoscript.ru/courses/typenoscript

2. Стартовал набор в летнюю ШРИ(и другие школы Яндекса). Набор проходит с 15.03 по 27.04. Сама школа бесплатная, но нужно будет сделать тестовое и пройти отбор. Это крутой формат, чтобы прокачаться во фронтенде, и хорошая возможность, для тех, кто хочет устроиться в Яндекс. Я там буду читать лекции по Реакту. Все подробности тут https://academy.yandex.ru/schools/frontend

Ref callback
#Фронтенд

Я думаю, что все разработчики, использующие React, сталкивались с ref.

Используем хук useRef и прокидываем полученный объект в проп ref. Запускаем, получаем ссылку на DOM элемент и используем ее в нашей логике. Вроде нет ничего хитрого.

Большинство именно так и делают всегда. Но! Проп ref принимает не только объект. Если посмотреть в типы, то мы увидим, что туда можно прокинуть еще и колбэк.

Если мы прокинем туда функцию, то она будет вызвана, когда наш элемент замаунтиться(говорим про dom), и первым параметром она получит ссылку на этот DOM элемент. При анмаунте элемента(говорим про dom) она будет вызвана с null.

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

Мутанты
#Фронтенд

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

В js существует страшилка, что нельзя мутировать объекты. Ей пугают новичков с самых первых шагов. Давайте с ней разбираться.

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

Но все это привело к другой проблеме - полный отказ от мутации, совсем. Да, кто-то скажет это не проблема. Но я так не считаю. Сейчас очень активно, особенно новички, при каждой попытке изменить объект использует спред {...yourObject}. И многие воспринимают это прям как истинное добро и свет. Но есть проблема, операция {...yourObject} не отличается производительностью. Поэтому важно знать где нужно, а где ненужно мутировать. Это поможет избавиться от лишних спредов.

Самый популярный кейс избыточной иммутабильности это создание объекта на основе массива с помощью reduce(reduceRight). Большинства используют его как-то так:
array.reduce((acc, element) => ({ ...acc, [element.id]: element }), {})
Если остановиться и проанализировать этот код, то мы пытаемся спасти от мутации объект, который еще нигде не используется. Тк при запуске такого кода последовательность следующая: создание нового объекта => заполнение его свойств => складываем ссылку на него в переменную => потом где-то используем.

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

Сезон отпусков
#ПростоМысли

Доброе утро, работяги!

Сегодня ехал на работу, погодка супер, из окна так вообще как лето уже. Пришла идея немного побухтеть про отпуска.

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

Большинство своих отпусков я брал с какой-то целью. Целью отличной от отдыха. Я сдавал сессию, переезжал, делал ремонт и все в таком духе. Если никаких таких событий на горизонте нет, то нет и отпуска. И было норм. Хз почему, возможно моложе был, возможно задачи требовали меньше ресурсов. Не знаю.

Но постепенно я начал замечать усталость. И нет это не какая-то мифическая усталость. Просто быстрее устаешь. Усталость появляется не к ночи как обычно, а к вечеру. При этом утром я заряжен, я готов разрывать таски, творить и просто бегу на работу. Но к вечеру уже выжат. Я грешил на погоду, витамин D и многое другое.

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

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

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

Для тех, кто после прочтения собрался в отпуск, хочу посоветовать одну из моих любимых художественных книг - Первый Закон. Джо Аберкромби. Не советую читать вне отпуска, книга затягивает!

Продуктивной пятницы и хороших выходных, работяги!

Анонс ютюб канала
#Анонсы

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

Я создал свой ютуб канал.

Возможно позже добавлю другие платформы. На канале будет много всего интересного о программировании, но только уже в видеоформате.

Первым делом записываю видеожурнал про NextJs. Первый эпизод уже на канале - https://youtu.be/F9Vaac3h0pg

Я только начинаю делать видео, поэтому буду очень рад вашему фидбеку, пишите что понравилось, что нет в комменты)))

Отпуск заканчивается
#Анонсы

Я потихоньку начинаю выбираться из отпуска. Скоро выложу новые посты в канал)
А на ютуб-канале уже вышел новый выпуск видео-журнала о Next.js.

https://youtu.be/0UJhyhspYPw

Приятного просмотра!

Это база
#ПростоМысли

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

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

Для простоты введем сокращение ПТ - продвинутая технология, это может быть фреймворк, либо библиотека. Как пример React, Angular и тп.

Почему такой вопрос вообще возникает? Я предполагаю, что пошло это из найма, ведь если мы откроем вакансии для фронтендеров, то увидим огромное количество заголовков в духе - "Ищем junior/middle/senior React/Angular/Vue разработчика". Уже в самом заголовке выставлен акцент на ПТ. Хорошо ли это? Не думаю. Скорее даже опасно.

Начинающие разработчики спешат поскорее найти свою первую работу. Для этого они стараются максимально соответствовать тем описаниям вакансий, которые они видят. А там акцент выставлен на ПТ. Следовательно складывается впечатление, что нужно поскорее выучить именно ПТ. И вот тут они допускают ошибку.

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

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

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

Труд!

Доброе утро, работяги!

Праздник труда закончился, а результаты остались.

На канале вышел новый выпуск про Next.js. В нем мы с вами разберемся с роутингом.

Приятного просмотра - https://youtu.be/RIA5N660mr8

Расширяемся

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

https://vk.com/temaprogchannel

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

Всем продуктивной недели!