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

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

Если в стандартном подходе эта задача лежит на backend разработчике, который часто имеет смутное представление о UI и об использовании там полученных данных. То в подходе GraphQL он просто даёт возможность вернуть все поля, какие есть, а frontend разработчик решает, что именно ему нужно. Такой подход, с одной стороны избавляет от подобных трудностей, а с другой, избавляет от ситуации, когда с сервера приходят ненужные данные.

Если ещё не пробовали данный инструмент, то очень рекомендую.

Одна из самых частых проблем в разработке - плохая постановка задачи. С одной стороны может показаться, что это слишком долго, описывать подробно. Однако, довольно часто оказывается, что очевидные вещи для одного человека совсем не очевидны. И постановка, в которых автор задачи решил, что не будет делать как надо, приводит к куче вопросов со стороны разработчика, непонимания правильного поведения со стороны QA, а также к огромному количеству бесполезно потраченного времени. А стоит ли того выгода от сэкономленного времени на подробное описание задачи?

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

Тут можете почитать подробнее:
https://habr.com/ru/companies/simbirsoft/articles/507394/

Плюсы и минусы работы в аутсорс компании:

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

Минусы:
🔹Бывает, что команда относится к сотруднику, как к чужому.
🔹Могут отсоединить от проекта одним днём. Сегодня ты на проекте, а завтра уже нет.
🔹При закрытии проекта, может не оказаться проекта на тот же стек.

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

Иногда, библиотеки облегчают жизнь и ускоряют разработку, а иногда наоборот, делают код приложения менее читаемым и чрезмерно его усложняют. Как пример, могу привести библиотеку Formik. С одной стороны, она облегчает процесс создания форм. С другой, в случае, если валидация формы сложная, с большим количеством ошибок, которые приходят с сервера и которые также нужно отобразить (неправильный код из смс, несуществующий email), то эта библиотека, с её автоматической валидацией, приводит огромной массе конфликтов автоматических и серверных ошибок.

MobX или Redux?

Работал долгое время с обеими библиотеками и если честно, то так и не смог выбрать для себя фаворита.

С одной стороны, строгая, с огромным количеством сущностей и терминов, Redux. Естественно, в своём первозданном виде она явно проигрывает, то вот в составе redux-toolkit, она не уступает MobX. И всё же, на мой взгляд, redux-toolkit сильно усложнена.

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

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

Собеседование в зарубежную компанию

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

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

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

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

Чем мне помогло ведение канала на YouTube

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

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

А вот и мой YouTube канал: https://www.youtube.com/@dmitrii_gerasimov

Три вещи в разработке, которые изначально вызывали у меня недоумение

🔹Для чего нужно ООП. Изначально, когда изучали программирование в университете, мы несколько месяцев не использовали подход ООП. А потом, начали изучать все эти основные определения из ООП и переходить на данный подход. Не осознавая, на тот момент, как он сильно облегчает жизнь, мне он казался избыточным.
🔹Для чего нужен TypeScript. Довольно долгое время мне попадались проекты без TypeScript. И когда я видел, что люди добавляют типизацию, которая и так очевидна, у меня возникал вопрос: "Зачем?". Естественно, в дальнейшем я узнал, как трудно поддерживать проекты без типизации, но тогда...
🔹Зачем хуки в React. Очень долгое время, работал с React до того, как эти хуки появились. Я выучил все эти названия методов жизненного цикла. Даже сейчас их все помню, хотя не писал их несколько лет. Но когда хуки появились, то мне казалось, что изобрели что-то, что уже и так есть.

На моём текущем проекте, разработчики, которые начинали его разрабатывать, по какой-то причине приняли решение не использовать готовую библиотеку компонентов, а подключать отдельные библиотеки по мере необходимости. Всё это приводит к тому, что каждый раз приходится смотреть, какую библиотеку следует использовать. Тратится время на поиск, на установку, на тестирование. Порой, довольно нетривиальная задача, ибо большинство разработчиков используют что-то типа Material UI, Ant Design или Bootstrap, поэтому, библиотеки с каким-то отдельным компонентом, чаще всего пребывают в плачевном или заброшенном состоянии.

В какой стране можно изучать английский без проблем?

Я думаю, что не для кого не секрет, что английский для разработчика - это очень необходимый навык. Он помогает облегчить жизни и даёт дополнительные возможности. Скажу честно, что в России довольно мало возможностей его практиковать. Можно только принудительно ходить в разговорные клубы, либо изучать его онлайн. Однако, в повседневной жизни он не встречается. Идеальные условия - это использование английского в повседневной жизни. Но так сложилось, что англоязычные страны, либо требуют визу и стоимость жизни там высокая, либо в них есть проблемы с безопасностью. Так как же быть? Есть выход -- изучение английского в Сербии. Если говорить про её столицу - Белград, то здесь трудно найти человека, который плохо говорит по-английски. К тому же. тут без проблем можно задержаться надолго и стоимость жизни здесь не такая высокая.

Online codding

Я думаю, что самое неприятное в прохождении собеседований - это online codding. Довольно многим тяжело даётся написание кода в тот момент, когда на тебя смотрят. Частенько ещё просят комментировать то, что ты делаешь. И причина ясна. Когда разработчик пишет код на работе, то за этим процессом никто не наблюдает. Поэтому можно писать достаточно свободно, никто не осудит за ошибки. Раньше мне тоже было очень сложно это делать. До сих пор помню свой первый опыт около 6 лет назад, когда меня собеседовал надменный разработчик. Написать что-то я тогда не смог. Но то, что мне помогло - это изменение отношения к собеседованию. Я просто делаю то, что могу. А что не могу, то не в моих силах. И такой подход помогает мне проще относиться к любому интервью. Сейчас, online codding для меня, не проблема.

Мы хотим еще раз сказать спасибо всем, кто принял участие в нашем митапе🧡

У нас готовы фотографии с мероприятия!
Можно посмотреть и скачать по ссылке.

Будем очень рады, если пройдешь маленький опрос по мероприятию⬇️
https://forms.gle/wBTg4pPrZFWcaNbx5

Подписывайся, чтобы быть в курсе всех новостей:
Instagram | Facebook |Telegram

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

Опыт во фрилансе - не опыт?

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

Опасность memo в React

memo - довольно мощный инструмент, который помогает избежать лишние перерисовки компонента. И если мы используем memo, то естественно для того, чтобы это имело смысл, необходимо использовать useCallback для тех случаев, когда мы будем передавать функции в качестве параметров в компоненты. Однако это кроет в себе скрытую опасность, которая может привести к непониманию, почему в некоторых случаях мы не получаем актуальные значения данных, переданных в массиве зависимостей в функции, обёрнутой в useCallback. Это происходит тогда, когда эту функцию параметр мы попробуем использовать в useEffect или в другой функции, обёрнутой в useCallback, а точнее в том случае, если мы забудем указать эту обёрнутую в useCallback функцию в массив зависимостей.