Что делать, если постановка задачи плохая?

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

🔹Скудное описание - когда просто не понимаешь, что от тебя хотят.
🔹Много всего лишнего - когда постановка включает в себя, также, информацию для других сотрудников, либо вообще не связанную с задачей информацию.
🔹Устаревшую информацию - постановка делалась много месяцев назад.

И как же быть? В идеальном мире, просто вернуть задачу автору с комментарием. И это очень мотивирует авторов не делать так в будущем.

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

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

К чему приводит отсутствие code review?

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

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

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

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

Когда я только начинал работать разработчиком, я очень боялся показать, что моего опыта не хватает в каких-то вещах. У меня, естественно, были пробелы в знаниях, особенно в части инструментов для командной разработки, например 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.

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