Полезные советы для junior-специалистов

Нужно разобраться с Git, а также с семантическим версионированием

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

После того, как вы приступите к работе в команде, вас смогут познакомить со столь концептуальными стратегиями, как:

пул-реквесты (они же PR, как называются они на GitHub),

мердж-реквесты (их называют PR уже на GitLab),

merging (это слияние),

rebasing,

squashing commits, а также

semver (semantic versioning, то есть семантическое версионирование).

Delete prod

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

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

- в чем состоит разница между merging и rebasing?

- когда необходимо делать rebase?

- как именно функционируют номера версий?

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

На стендапы необходимо ходить подготовленным

Если команда ваша практикует agile, вы должны готовиться рассказывать на стендапе о таких вещах, как:

- чего вы смогли добиться вчера;

- над чем вы сегодня трудитесь;

- что мешает вашей работе.

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

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

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

Не стесняйтесь просить о помощи

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

Просить о помощи тогда, когда она вам нужна – это полностью в ваших интересах (а еще это и в интересах компании также).

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

Личная просьба помочь

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

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

Просьба о помощи посредством мессенджера

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

Вот для начала плохой пример просьбы о помощи: «Эй, ты можешь помочь мне? У меня не получается поставить node.js на моем ПК, он не функционирует».

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

Вот хороший вариант обращения:

«Привет, Сергей, это Дмитрий, я новый разработчик. Очень приятно познакомиться. Как я слышал, ты можешь оказать мне помощь с проблемой, которую я сейчас пытаюсь решить. Я пытаюсь поставить на свой ПК Node.js. Я уже попробовал эту ссылку (здесь вставляется ссылка) и делал по инструкции, но после того как я запустил данную команду (здесь вставляется команда), я увидел сообщение об ошибке (приводится текст сообщения). Я использую в работе один из новых макбуков. Можешь ты подсказать, в чем здесь может быть проблема?».

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

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

Как вести себя, когда вам оказали помощь

Прежде всего, позабудьте о вашем эго.

Если человек тратит время, чтобы помочь разобраться с вашей проблемой, то не стоит изображать, что вы и сами знали, как справиться с данной задачей. После того, как проблема решена, не надо говорить – «именно так я и собирался поступить». Достаточно просто поблагодарить коллегу.

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

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

Обязательно тестирование кода вручную

Код необходимо проверять. Тестируйте happy paths (речь о типовых путях выполнения кода) и, в особенности, не забывайте тестировать non-happy paths. Постарайтесь сами сломать ваш код. Запомните – если у вас в коде имеются баги, то пользователи рано или поздно их обязательно обнаружат. Так что лучше попытайтесь найти их сами. И даже если в вашей компании имеется команда QA, вашей целью является сделать так, чтобы эта команда в вашем коде ничего не нашла. Также учитесь создавать тестируемый код и тесты для этого кода. Подготовка тестируемого кода обычно находится за рамками вузовской программы, но на самом деле этому учишься, используя принципы SOLID.

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

Постоянно учитесь

Постоянное обучение – одна из главных  особенностей профессии разработчика. Если вы являетесь фронтенд-разработчиком, то занимайтесь изучением devops и бэкенд. Если же вы бэкенд-разработчик – тогда можно изучать HCI (взаимодействие ПК и человека) и UX.

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

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