Сегодня разбираем интересную тему: что ждёт джуниор-фронтендера на его первой работе. Мы пообщались с Даниилом Бердниковым, разработчиком в Яндексе и наставником Практикума, о том, какие типичные задачи бывают у новичков и как с ними справляться.
Типичная стартовая задача начинающего джуниор-программиста
Ситуация: представьте, что вы — джуниор-программист в ИТ-компании. И вам дали первую задачу: разобраться с мелким багом в коде. Вы ищете, прочитали уже всю документацию, почитали код, но никак не можете понять, где баг.
Теперь что делать в такой ситуации.
Лучше всего написать в тикет задачи (или в чат) и указать, что конкретно вы попытались сделать для решения этой проблемы. Например, я уже посмотрел здесь, попробовал вот это, но у меня, допустим, баг не воспроизводится. В этом случае вам уже смогут ответить более детально, куда смотреть дальше.
Навык локализации проблемы — это то, что нужно учиться отрабатывать с первых дней. На самом деле это несложно: постарайтесь просто отсекать те части, где этого бага точно нет. Как правило, вы всегда можете начать с широкого, постепенно убирать какие-то части — и локализовать хотя бы участок, где потенциально может быть этот баг.
Дальше: нет ничего зазорного в том, чтобы просто погуглить или посмотреть в документации, а откуда вообще может появиться какой-то баг и что с ним можно сделать. И это — второй важный навык для новичков. Умение самому пытаться находить решение — это стимул для роста в профессии.
Хорошо, если вы уже провели какую-то работу и приходите с промежуточными результатами. Например, собрали информацию, но не поняли, как её применить. Или поняли, но на практике столкнулись с чем-то неожиданным. Тут уже можно подойти к сеньору и спросить, как стоит поступить в этой ситуации (и дать свои варианты решения). И потом обязательно уточните, как сделать лучше или почему это работает вот так. Но задавать примитивные вопросы, ответы на которые легко найти, точно не нужно.
Как быстро погрузиться в новый и незнакомый проект
Представим ситуацию, возможно, типичную для многих проектов. Вы приходите в новую компанию и узнаёте, что там используются довольно специфичные библиотеки. Не привычные Ангуляр с Реактом или NumPy, а что-то очень узкопрофильное. Когда-то в компании начали это использовать, потом им понравилось, и это уже превратилось в легаси, но так как это решает задачу, такие библиотеки везде используются и тянутся до сих пор. А вы вообще первый раз в жизни слышите про этот фреймворк (или слышали про него, но ни разу в жизни не работали с ним).
Что здесь делать новичку, как ему быстро погрузиться в такой проект?
Тут лучше всего смотреть, как сделаны аналогичные места в том же самом проекте. Это лучше документации, особенно если, по сути, формальных доков нет.
Допустим, вы делаете определённую страницу — тогда посмотрите, как сделаны страницы соседние. Скорее всего, будет плюс-минус одинаковая структура, они выполняют плюс-минус одинаковые задачи, но всегда есть куда подсмотреть, чтобы понять, а как оно вообще работает.
И это — универсальное правило. Даже если у компании есть свой самописный фреймворк и к нему нет вообще документации, то всё равно у вас вокруг уже достаточно большое количество примеров кода, который делает то же самое. Практически в 99% случаев вам будет куда подсмотреть. Просто надо внимательно всё изучить и для себя понять логику сначала отдельных элементов, а со временем — и системы в целом.
Честный разговор с тимлидом о том, чего ждут от джунов во фронтенд-разработке. Часть первая: теория и технологии
Честный разговор с тимлидом про фронтенд для новичков: как набить руку, нужен ли бэкенд и что такое чистая вёрстка
Разговор с тимлидом: как разбираться в коде, что происходит после онбординга и первые рабочие задачиСамые популярные задачи у джуниора во фронте
Отработка багов
Про неё мы поговорили в самом начале. Добавим, что это действительно то, с чего начинает большинство джуниоров, потому что это самый простой и полезный способ погрузиться в новый проект.
Техническая вёрстка
Если мы говорим о коммерческих сайтах, то это вёрстка огромного количества страниц и элементов. Условно, вам приносят картинку (или ссылку на Фигму) и говорят сделать так же, но уже в вебе. Это достаточно механическая работа, она относительно несложная и как раз уровня джуниор-разработчиков.
Технически это HTML, CSS плюс JS, потому что большая часть вёрстки является сейчас интерактивной, там могут быть и более сложные анимации или параллаксы. Мало ли что дизайнеры напридумывали. А ещё там могут быть базовые задачи валидации, интерактивности (типа открыть-закрыть, переключить вкладку) — и это всё закрывает JavaScript.
Работа с шаблонами и CMS
Здесь мы говорим уже про заказную разработку. Заказная разработка вообще отличается разнообразием того, что предстоит там делать :)
Например, нужно будет взять Вордпресс и натянуть на него шаблон. Или взять картинку от дизайнеров и сделать точно так же на какой-то другой CMS — и здесь уже нужно знание PHP и базовых принципов работы движка.
Что не стоит делать начинающему разработчику
Что плохо повлияет на репутацию, на развитие, либо и на то, и на другое вместе.
Грохнуть историю коммитов в репозитории
Это абсолютный лидер среди того, что новички могут сделать случайно.
Как это происходит:
- вы получили свою первую задачу;
- склонировали репозиторий;
- радостно кинулись решать задачу;
- потом сделали commit, сделали push, а репозиторий говорит, что нет, что-то нельзя, там что-то есть;
- но вы это не прочитали, вы увидели там параметр «используйте force».
И вы такие push --force туда. Всё, история коммитов стирается, а потом сеньоры всё пытаются восстановить. Через это прошли все команды и большое количество джунов.
❗️ Забудьте про push --force, не используйте до тех пор, пока не будете знать, что это и зачем это нужно. Просто будьте сначала внимательны, не спешите. Очень многие приходят и начинают сразу бросаться на амбразуру, спешить, пытаться быстрее сделать. Сначала познакомьтесь с системой, с кодом и всегда принимайте продуманные решения.
Понимаете, хороший разработчик — не тот, кто пишет много кода, а тот, кто пишет мало кода, но хорошо анализирует поставленную задачу и принимает верные решения. Потому что мы всё-таки инженеры, а не просто писатели на машинке.
Игнорирование корпоративных стилей и правил
Здесь речь про игнорирование корпоративного стайлгайда, неиспользование того, что уже есть в разработке, —то есть разработка каких-то своих велосипедов. Как правило, в компании уже сложилась определённая культура, как пишется код, как документируется, организовывается, какие есть готовые решения. И, как правило, это всё можно где-то посмотреть, либо спросить, как лучше поступить.
Непрошенное улучшение
Тоже частая проблема, когда новичок приходит и начинает пытаться придумать что-то своё, пытается учить, как лучше делать, или, например, говорит, что вот здесь можно было бы сделать лучше, а вы сделали неправильно.
Постарайтесь понять, что вы только пришли в команду и не видите всей картины, и, скорее всего, есть причины, почему здесь было сделано так. Вы просто пока ещё эти причины не знаете.
Сначала пытайтесь просто сделать то, что попросят, и максимально подстроиться под тот ритм и под тот стиль, ту культуру работы, которая сейчас есть в команде. И только потом уже можно будет предлагать нужное. Это не значит, что всегда следует сидеть тихо, ничего не предлагать, не проявлять инициативу. Инициатива — это хорошо, особенно если у вас она продуманная и аргументированная, но для этого сначала нужно полностью во всём разобраться, а на это требуется время.
Неуважение к другим профессиям
Ещё одна важная проблема — неуважение к смежникам, которые работают с вами в команде. К сожалению, бывает предвзятое отношение к дизайнерам, проект-менеджерам, тестировщикам. Здесь важно научиться понимать, что все эти люди вместе с вами работают над проектом, выполняют свою важную роль.
Может, поначалу вам и не нравится, что тестировщик сломал вашу прекрасную форму, ваш прекрасный код и приходит к вам с какими-то багами. Или дизайнер вдруг решил немножечко подвинуть какой-то пиксель, а вам из-за этого всё перевёрстывать. У всех могут быть какие-то причины на это, и они хотят сделать продукт лучше, ваша общая цель — сделать так, чтобы пользователю было хорошо.
Про харды и софты
Софты качаются медленно, а вот харды — это то, что придёт с опытом.
Софты — общение, внимание и умение организованно подходить к решению задач. Это самое ключевое, то, что очень тяжело прорабатывается. Бывает такое, что приходят ребята, которые вот вроде классные разработчики, но по софтам и умению общаться прям полный швах, из-за этого с ними приходится расставаться.
Отсюда вывод: ребята, качайте софт-скилы, учитесь общаться с другими участниками команды, смежными командами и так далее. Потому что разработка — это не только написание кода, это большая часть времени общения с людьми, постановка задач, выяснение, что всё-таки нужно сделать.
А харды качаются очень быстро, буквально через 2–3 года это вообще перестанет для вас быть проблемой. Но вот софты с вами навсегда и они часто важнее, чем знание какой-то библиотеки.
Вам слово
Приходите к нам в соцсети поделиться своим мнением о статье и почитать, что пишут другие. А ещё там выходит дополнительный контент, которого нет на сайте: шпаргалки, опросы и разная дурка. В общем, вот тележка, вот ВК — велком!
