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

Путь разработчика

Когда я только начинал работать разработчиком, я очень боялся показать, что моего опыта не хватает в каких-то вещах. У меня, естественно, были пробелы в знаниях, особенно в части инструментов для командной разработки, например repository, ci / cd. И за счёт этого, у меня возникали проблемы, поскольку я, не понимаю чего-то, не говорил об этом напрямую, а пытался догадаться сам.

Когда я стал работать с начинающими специалистами, будучи senior разработчиком, я замечал, что у этих начинающих специалистов наблюдается всё та же ситуация.

Хочу сказать, что если что-то не понятно и возникает вопрос, то следует его задать. Частенько это очень сильно сэкономит время.

Путь разработчика

В университете я совсем не изучал разработку, но когда настало время выбрать специальность, я понял, что на тот момент web разработка была самым лучшим вариантом. Мне не хотелось решать какие-то упражнения, я хотел делать проекты. И я решил делать развлекательный портал. На тот момент мне казалось, что я хочу стать PHP разработчиком, поэтому я стал делать проект именно на нём. В процессе изучения, я понял, что мне интересен frontend и я сделал небольшой проект и c использованием JavaScript и React. Это также помогло мне закрепить то, что я изучил, на практике. В процессе трудоустройства, я мог показать, что я действительно что-то сделал. Также я в открытую писал в своих резюме, что я работал над своими проектами, что и было моим опытом работы. Помню, что на первом месте работы мне организовали большое review кода. Даже подумывали взять на middle позицию, но отсутствие коммерческого опыта не дало это сделать. Я считаю, что именно те проекты помогли мне найти свою первую работу.

Путь разработчика

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

Patch
String
Branch
Framework
Development
Deploy
View
Reducer
Loop
Net

Путь разработчика

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

Путь разработчика

Мне всегда было интересно уметь делать не только frontend, но и backend. Поэтому node.js я тоже использую в своих приложениях. Почему именно node.js? Потому, что это самая популярная технология для frontend. Но вот что изучать? Проанализировав кучу вакансий на позицию full-stack разработчика, я пришёл к выводу, что сейчас популярны:

Next
Nest

Причём, трудно выделить что-то из них. Они немного разные и у них есть существенные отличия, но они оба сейчас в тренде.

Путь разработчика

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

Путь разработчика

🔹Разбираться в плохой постановке задачи. Порой, постановка может состоять из одного заголовка. И возникает вопрос: "Почему так?" И ответ будет - потому что автору задачи было лень делать постановку, либо она казалась ему очевидной.
🔹Правильно задавать вопросы. Исходя из предыдущего пункта, становится очевидно, что проблема с постановкой - очень частая проблема. И в таком случае, нужно задавать правильные вопросы, чтобы получать именно то, что важно, затратив как можно меньшее количество времени.
🔹Учится себя презентовать. Если у Вас страх публичных выступлений, то от него придётся избавиться. Постоянное прохождение собеседований, а также выступления на различных групповых встречах - это необходимое условие в работе разработчика.
🔹Умение взаимодействовать с различными людьми. В команде часто бывают люди, которые имеют не самый простой характер. Избежать общения с ними, когда речь идёт о каких-то рабочих моментах, не получится. По этой причине, придётся учиться взаимодействию с ними.

Путь разработчика

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

Путь разработчика

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

🔹Не оцениваю баги. В этом нет особого смысла. Да и руководитель этого не требует. Баг может быть исправлен за несколько минут, а может за несколько часов.
🔹Для руководителей главное, чтобы уложился в оценку, а не чтобы она была наименьшей.
🔹Декомпозиция - максимально разбиваю задачу на небольшие блоки. Маленькие блоки оценивать легче.
🔹Не поддаюсь на мысли, что можно сделать быстрее, если в голову приходит оценка. Всегда, когда я поддавался таким мыслям, я не попадал в оценку.
🔹Обязательно нужно закладывать риски, около 20% от задачи. Очень часто это помогает уложиться в срок.
🔹Если это возможно, то оцениваем задачи в паре с другим разработчиком. Берём максимальную оценку из тех, что определили.

Путь разработчика

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

Путь разработчика

Когда мой английский был слабоват, но я работал разработчиком несколько лет, то заметил за собой забавную особенность. Я знал огромное количество названий методов и сущностей, однако мне не приходило в голову посмотреть из перевод. В результате получалось, что порой у меня в голове путались некоторые похожие слова, например slice и splice. И такое положение вещей складывалось до тех пор, пока я не взялся за изучение английского языка всерьёз. И сейчас, мой мир стал гораздо более понятным и простым. Было ли у Вас подобное? 🙃

useCallback - довольно распространённый хук в React, но не все понимают, для чего он нужен. Представим, что у нас функция a(), объявленная внутри компонента, которую мы передаём в React компонент B, обёрнутый в memo, в качестве параметра. Поскольку все компоненты - функции, то при каждом запуску функции - компонента, будет создаваться новый экземпляр функции a(). Объект функции a() каждый раз будет другим. И компонент B каждый раз будет думать, что функция a() - другой параметр, ведь он сравнивает значения параметров по значению. В результате, при каждом рендеринге родительского компонента, компонент B также будет рисоваться заново, ведь значение параметра меняется. Чтобы избежать избыточных перерисовок компонента B, мы можем обернуть функцию a() в useCallback. Это поможет не создавать новый экземпляр функции a() при каждом рендеринге родительского компонента, а следовательно, параметр не будет каждый раз изменяться. Тем самым, мы избежим избыточных рендерингов компонента B.

Путь разработчика

Очень частый вопрос на собеседовании: "Почему плохо использовать индексы в качестве keys в React?" На самом деле, это плохо не всегда. Это плохо только в тех случаях, когда порядок node может измениться. Например, если происходит сортировка массива nodes или добавление новых элементов в начало или середину массива. Почему это плохо? Потому, что при подобных операциях теряется соответствие node и индекса, который выступает в качестве key . Если же мы используем в качестве key уникальный id из объекта - элемента массива, то при любом изменении порядка элементов, соответствие node и key будет сохраняться. Если же мы точно знаем, что элементы массива nodes не будут менять порядок, то индекс в качестве key - неплохое решение. Иногда, другого выхода просто нет.

Путь разработчика

Сравнивая строки в JavaScript с помощью операторов сравнения (<. >, ===), Вы можете обнаружить, что, например "ё" > "я", что с точки зрения языка выглядит странно. В чём же причина? А причина сравнения кодов этих символов в UTF. Но почему же так разработчики UTF просто не задали всё в правильном порядке? А причина в том, что когда мы говорим, например, о латинице или кириллице, то имеются ввиду латиница и кириллица в целом. Например, латиница используется в английском, турецком, хорватском. И у каждой из них есть свои символы и свой порядок букв в алфавите. Для оптимизации и удобства, они не дублируются для каждого языка. Учитывать порядок символов в алфавите каждого языка - нетривиальная задача.

Благо, в JS есть функция str.localeCompare(str2), которая учитывает особенности языка. В ней сравнение происходит по алфавиту. Если str < str2, то получим -1, если str = str2, то получим 0, а если str > str2, получим 1.

Путь разработчика

Недавно решил порешать задачи на алгоритмы. Вот моя реализация стека

class Stack {
_data;

push (payload) {
this._data = {
payload,
prev: this._data,
}
}

pop () {
const total = this._data;

this._data = this._data.prev;

return total;
}

toArray () {
const total = [];
let data = this._data;

while (data) {
total.push(data.payload);

data = data.prev;
}

return total;
}
}

Вчера я окончательно разочаровался в библиотеке Formik. Задача была в том, чтобы добавить новую простую форму с одним полем. Но по структуре приложения получается, что она оказывается внутри другой формы. И благодаря этому, у неё перестал работать preventDefault. И с этим ничего не поделаешь. Форма запускает его самостоятельно и не передаёт объект event в обработчик события. Да, там есть возможность обойти это, не самым красивым способом. Но это ещё больше усложнит понимание. К тому же, в моём текущем приложении предыдущий разработчик написал обёртку, которая не даёт доступа даже к этому. В общем, сплошное разочарование и впустую потраченные часы, на то, чтобы понять, что идёт не так.

Путь разработчика

I cannot understand people who have experienced doing something in the past, but cannot continue to do that again because it was a long time ago. Time after time I was in circumstances when I had to do that this way. For example, I lived in a country when I was not driving for a long time. In my case it was 1.5 years. And after that I ерщгпре that I had forgotten all about it. But when I started driving again in a couple of minutes I felt that there was not that pause and I felt the same as before the pause. The same was when I had a pause in working as a head of department. It was unused the first time, but after a couple of weeks it was the same as it was before the pause for 2.5 years. And I have the same feeling when I did not write code for several months. And for example I had not performed at a meetup for 3 years. And after that long time of pause I decided to do that again. And it was not difficult.

Путь разработчика

Сотрудники из VK рассказывают, что они спрашивают на собеседованиях (конспект их речи на 1.5 часа)

Что будет после того, как ввели адрес сайта в адресную строку. От начала и до отображения конечного результата.
Какие типы данных есть в JS. Чем отличается null или undefined.
Приведение типов. Не обязательно складывать всё со всем. Приведение типов toString, valueOf, и другие… Разница двойного и тройного равно. Приведение типов к boolean.
Что такое замыкание и область видимости. (Может на примере). Какой-то кусок кода могут показать. Почему так работает.
Цепочка promise (then, catch). Сложные цепочки.
Hosting переменных (всплытие)
Стрелочная и обычная функция. Задачи.
call, apply, bind.
Что такое this. Контекст.
Event loop. Макро и микро задачи.
События в js. Обработчики событий.
Прототипное наследование. И в целом, наследование в JS.
Почему CSS называется каскадной таблицей стилей. Как работает каскад.
Способы позиционирования и центрирования
Cookies
CORS
Методы массивов и объектов.

Путь разработчика

WebSocket

Особенности:
🔹Клиент инициирует постоянное соединение
🔹Сервер может самостоятельно давать ответ (без запроса)
🔹Каждая вкладка браузера - отдельное соединение

Минусы:
🔹Постоянное соединение, которое создает нагрузку
🔹Труднее в поддержке
🔹Отсутствует кеширование

Сфера применения:
🔹Чаты и мессенджеры
🔹Игровые приложения в реальном времени
🔹Мониторинги состояния критически важных сервисов в реальном времени
🔹Торговых приложениях с обновлением статуса заказов в реальном времени (финансовые биржи, аукционы)


Путь разработчика

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

Не секрет, что для привязки контекста используется метод функции, который называется bind.

Но что произойдет, если вызвать этот метод дважды?

Ответ прост: bind привязывает контекст только один раз. Все последующие попытки привязки не дадут результата.

В приведенном примере мы увидим в консоли строку "Dima". И это останется неизменным.

Путь разработчика