Советы джуну на первом проекте

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

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

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

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

Подготовься перед началом работы

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

У меня была такая ситуация: я начинал работать в компании где проект был написан на React и TypeScript. Продакшен-опыта с React у меня на тот момент не было, а с TypeScript я вообще не сталкивался. После того как я прошёл все этапы собеседований и принял офер у меня был почти месяц до выхода на работу. Я спросил будущего руководителя чтобы я мог посмотреть или почитать чтобы мне было проще начать работу.

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

Проясни ожидания

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

Уточни какие есть ожидания на первый месяц работы. Обычно за этот период ты успеешь:

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

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

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

Найди кого-то, к которому можно идти с вопросами

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

В крупных компаниях часто есть онбординг: к новичку прикрепляют человека, который помогает адаптироваться. Это может быть руководитель, ментор или просто разработчик, который давно в проекте и знает “как тут всё устроено”. Но если такого человека тебе не назначили — найди его сам.

Это может быть:

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

Очень помогает заранее договориться как часто ты будешь к нему приходить с вопросами:

• ты собираешь вопросы списком и приходишь 1-2 разв в день,
• или пишешь по мере появления вопросов.

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

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

• погугли,
• спроси у AI,
• поизучай код,
• подебажь.

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

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

Записывай

На проект у тебя будет много вопросов и получая на них ответы ты через какое-то время будешь их забывать. Чтобы не спрашивать по несколько раз одно и то же － записывай ответы. Создай себе базу знаний по проекту. Это может быть Notion, Obsidian, заметки или записи в обычном блокноте. Главное — чтобы ты потом мог быстро найти нужную информацию.

Я обычно записываю всё что может мне помочь составить полную картину проекта. Это может быть

• непонятные абривиатуры и термины;
• принятые в команде подходы к написанию кода с которыми я раньше не сталкивался;
• записи о том что где в проекте лежит.

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

Пойми кто в команде в чём разбирается лучше

Обычно в команде экспертиза распределена неравномерно: кто-то лучше знает, как работает сборка, кому-то больше нравится работать со стилями и вёрсткой, а у кого-то глубже экспертиза в SEO и оптимизации перформенса.

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

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

Также понимание сильных сторон каждого в команде может показать, какой экспертизы не хватает, и где ты можешь принести больше пользы.

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

У нас как-то даже была специальная таблица в Confluence, где были перечислены все участники команды с указанием их специализации. Правда, эта дока была сделана для ребят из других команд, чтобы они понимали, к кому обратиться, когда у них есть вопросы по нашему проекту. Но новичкам она тоже могла бы пригодиться, если бы мы додумались показывать её во время онбординга.

Читай и пиши документацию

Если на проекте есть документация － прочти её. Только предварительно уточни насколько она актуальная. Она может быть устаревшая и тогда будет не такая полезная для понимания проекта.

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

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

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

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

Тесты

Если на проекте есть тесты － обязательно прочти их. Хорошо написанные тесты могут служить документацией для проекта. Обрати внимание есть ли на проекте e2e тесты. Они обычно пишутся на реальные юзер флоу и обычно самые важные флоу покрыты ими.

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

Рефакторинг

Следующий способ хорошо разобраться в коде проекта － это рефакторить легаси код. Например, когда я только пришёл работать в 2gis одними из первых задач было переписать классовые React компоненты на функциональные компоненты с хуками. Это очень помогло мне разобраться как принято писать компоненты в проекте и как происходит работа со стейтом.

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

Читай PR’ы

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

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

Завершение

Это все советы которые у меня есть. Надеюсь было полезно. Если ты знаешь кого-то кому оно может быть тоже полезно, поделись с ним. Спасибо!