Эту статью мы делаем вместе с Алексеем Мартыновым — разработчиком и предпринимателем с более чем 20 годами опыта в ИТ. А ещё Алексей — программный директор на Веб-факультете Практикума и технический директор в проекте Akil.io. Сегодня поговорили с ним о том, что ждёт джуниоров в самом начале их фронтенд-пути в компаниях: проблемы, задачи и как со всем этим справиться. В статье нет сквозной истории, вместо этого мы собрали самые интересные моменты и мнение Алексея по этому поводу.
Заодно зацените, как выглядит настоящий тимлид:
Джуниор приходит в заказную разработку
Ситуация: джуниор после курсов хочет пойти работать в компанию, которая занимается заказной разработкой. И здесь часто интересуются, будут ли действительно использоваться в работе все эти алгоритмы, которые так любят спрашивать на собеседованиях. На самом деле ли будут настолько сложные задачи?
Нет. По большей части у джуна задачи, как правило, простые. Сложность заключается в другом: вы можете получить совершенно другой стек, не тот, который ожидали. Свежий пример: один из студентов, который изучил наш обычный стек, Node.Js на бэкэнде, React и всё такое, попадает в компанию — и тут же кидают на ASP.NET. Сказать, что он был удивлён — это ничего не сказать :) Другой вариант: к вам могут прийти и сказать, например, чтобы вы сразу делали целиком сайт на WordPress и на PHP, с которым вы, например, тоже вообще не знакомы.
В заказной разработке будьте уверены только в том, что вам точно пригодится вся база по HTML, CSS и JS. Дальше будете разбираться по обстановке, готовьтесь к этому заранее.
У меня есть пример студента, который за год успел в такой компании на заказах пройти практически большую часть существующего фронтенд-стека. Он пришёл на Vue, потом у него был React, потом Angular, потом он на нескольких CMS поработал, у него было несколько бэков и на Python, C# и JS. Он прошёл всё и в конце года просто сделал вывод, что главное — знать хорошо свою базу, и с этим можно двигаться дальше в любую сторону. Но это, конечно, жёсткий путь.
Если вы знаете базу и хорошо разбираетесь в своём стеке, то изучить остальное, подтянуть навык или язык — это вопрос примерно двух-трёх месяцев, чтобы после этого уже можно было начать приносить пользу компании.
Про чтение кода
Одно из заблуждений новичков — в том, что разработчик пишет много кода.
На самом деле разработчик больше читает код, чем пишет. Это первое, чему вам надо научиться: быстро читать и разбираться в том, что вообще происходит, в каком контексте вы находитесь, потому что меньшую часть времени, 20%, вы будете писать код, а 80% вы будете его читать.
Сюда относится код, например, из документации, или код проекта, в котором вы работаете. Здесь сразу важно отметить, что, как правило, вам редко дадут что-то вот прям с нуля делать. Это уже задачи всё-таки мидлов и сеньоров. Чаще всего вы будете работать в готовом окружении и вам нужно научиться из этого окружения черпать информацию. Там есть почти все ответы, как правило, на всё, что вам нужно сделать, просто надо быть внимательным.
Теперь что касается самого навыка чтения кода.
Сначала важно уметь просто понимать, что происходит на каждой отдельной строчке, но потом нужно научиться видеть картину в целом. И нужно научиться читать код не как книжку. Когда я провожу собеседования для студентов или джуниоров при приёме на работу, то всегда даю задачу по чтению кода. И это очень показательно.
👉 Код — это не книжка, его не читают сверху вниз, когда открыли файл и пошли его листать. Код нужно читать в том порядке, в котором он исполняется.
Круто, если разработчик открывает редактор и тут же сворачивает все абстракции, а потом начинает последовательно разворачивать классы и методы только тогда, когда ему нужно туда реально заглянуть. При чтении кода важно не то, например, как описан каждый метод в классе, а то, какие вообще у него методы есть, чем вы можете пользоваться.
И дальше вы прочитываете код в том порядке, как он будет исполняться. Это нужно, чтобы понять логику, что вообще здесь происходит и как это работает в целом.
Тест на понимание: «Расскажи, что происходит в этом коде»
Есть такой метод собеседования либо тестирования, когда более опытные разработчики хотят проверить, что за джун к ним пришёл, и говорят: «Слушай, а расскажи, что происходит в этом коде». Такое часто практикуется, сам так делаю, и это достаточно популярная штука, она очень много всего показывает.
Чаще всего такое бывает с тестовыми заданиями, когда просят объяснить свой код. И то, как человек отвечает на этот вопрос, тоже показатель того, взял ли он где-то в интернете этот код, сгенерировал его через условный ChatGPT или действительно написал сам.
Другая сторона этого — в коммуникациях. Большую часть времени вы так или иначе будете общаться с другими разработчиками. У вас должна быть техническая речь и умение сформулировать свои мысли и решения, связанные с кодом и его реализацией.
Команде и тимлиду важно оценить не только ваши хард-скилы, потому что у джуниора на старте может их быть очень мало, самая база. Здесь важна ваша перспектива и то, насколько вы вообще подходите команде. А по вашему ответу про код все смотрят, насколько с вами будет комфортно общаться, как вы можете объяснить и подать разную информацию. Поэтому уметь объяснить свой код или быстро разобраться в незнакомом, чтобы тоже про него рассказать, очень важный навык.
Как понять, что человек не разобрался в коде
Начнём с признаков того, что в коде никто не разобрался.
Если человек начинает просто читать вслух или сильно детализировать какие-то мелкие нюансы работы какого-то участка кода, значит, как правило, он не посмотрел на картину в целом или не может её в данный момент понять и озвучить. Иногда проблема бывает в том, что не знаешь, как выразить нужную мысль, — и этот навык тоже надо тренировать.
Не пытайтесь сильно детализировать. Нужно ответить коротко и лаконично, что конкретно делает этот код, в чём его функция, в чём его задача, а не то, как он это делает. Здесь важно «Что?» и «Зачем?», а не «Как?». Потому что «Как?» может быть сделано сотней разных способов. Если вы отвечаете на вопрос «Как это сделано?», значит, вы не разобрались в коде.
❌ Неправильно: код обращается к серверу с помощью JavaScript. Дальше мы получаем DOM-элемент, забираем из него данные, отправляем на сервер и выводим вот это.
✅ Правильно: здесь мы выполнили конкретную бизнес-функцию — поставили лайк вот в такой карточке. Вот что мы сделали. А как мы это сделали — это уже второй вопрос, чисто технический.
👉 Хороший программист отличается тем, что смотрит в суть того, что делает код, и обращает внимание именно на это, а не на конкретную реализацию, потому что её можно сделать разными способами.
Я рекомендую своим студентам при подготовке лайфхак, как можно взять и легко разобраться с любым термином или каким-то определением. Начните выписывать это определение и каждый раз пытайтесь выкинуть из него лишние слова. Делайте так до тех пор, пока не сократите его до такого, что уже всё, никакое слово не выкинешь, иначе теряется смысл. Вот это и будет суть.
Точно так же работает с кодом. Сначала вы читаете код и просто на каждой строчке объясняете: здесь мы собрали элементы, здесь мы их перебрали, получили из них вот это и это. Потом позже вы начинаете уже пропускать какие-то шаги: например, здесь мы получили список, а здесь мы его отправили. И так шаг за шагом учимся повышать уровень абстракции, чтобы ответить на вопрос, что же именно делает этот код.
Типичные задачи после онбординга
Итак, джуниора пригласили на работу, он прошёл онбординг — а что дальше? Какие типовые задачи перед ним в этот момент ставятся? Что ждёт новичка во фронтенде в самом начале карьерного пути?
В случае продуктовой разработки типичная задача — это чаще всего пофиксить какой-то баг. Например, где-то поехала вёрстка, где-то плохо отрабатывается реакция в скрипте или нужно добавить небольшую функциональность.
Чем хороши эти задачки: вы читаете код, погружаетесь в него и, как правило, они завязаны на том, что где-то в коде уже есть такое же решение и есть куда подсмотреть. Если вы просто внимательно изучите окружение, то найдёте нужное решение, заберёте и аккуратно перенесёте куда нужно. Именно поэтому такие задачи и дают джуниорам: так они быстро погружаются в код, процессы и то, как всё устроено.
Другое дело, что при заказной разработке, скорее всего, первыми задачами будут реализации какой-то функциональности. Например, вам могут сказать, что надо сделать новое поле ввода или целую форму регистрации. Здесь нужно быть готовым реализовать уже полноценную рабочую функциональность. А иногда в качестве задачи могут прийти даже целые страницы. Конечно, это будут не какие-то критичные для проекта задачи и за вами их всё равно проверят, но вы будете уже отвечать за гораздо большую кодовую базу.
Как подходить к первым рабочим задачам
Ситуация: человек пришёл в компанию, начал работать, и ему сразу говорят: «Слушай, здесь есть баг, давай разберись» или «Вот здесь что-то поехало в вёрстке, нужно посмотреть и поправить». А как вообще лучше всего подходить к таким задачам?
У одних такой подход: глубоко копаем всю документацию, изучаем все функции, поднимаем все исходники, смотрим все зависимости и так далее. Другие начинают сразу экспериментировать: открываем редактор кода, правим одно, смотрим, что изменилось, потом правим другое. А как правильно-то?
В первую очередь, конечно, лучше осмотреться и почитать сам код, который у вас появился в работе: понять, что он делает и как работает. Если там очевидный баг, то его можно сразу поправить. А если тут что-то сложнее, то познакомьтесь сначала с окружением.
Ещё не стесняйтесь спросить у своих коллег: возможно, они уже с ним сталкивались и быстро вам подскажут, что делать. Это не значит, что нужно тот же час бежать к ним по первой же проблеме. Сначала попробуйте сами её понять. Если вы можете сформулировать вопрос более конкретно и точно, то покажете своим коллегам, что как минимум разобрались, и хотите уточнить уже какие-то конкретные детали, а не просто как это исправлять.
Как найти баланс в решениях
У каждого джуниора поначалу есть проблемы с балансом: написать что-то быстро, но своё и с нуля, и не факт, что оно будет потом работать с другими компонентами; или потратить в несколько раз больше времени, но найти принятое в компании решение, которое точно будет переиспользоваться.
Баланс — где-то посередине. Если вы бросаетесь сразу в код, то можете сделать что-то лишнее или, например, не заметить, что решение уже есть в другой части кода, а вы его не переиспользовали. Взяли и запилили ещё код, а потом, когда потребуется, например, массово обновлять визуал, выяснится, что ваш код не использует какой-то переиспользуемый компонент и надо снова всё переделывать.
Но кроме такого подхода можно ещё смотреть на приоритеты. В продуктовой и заказной разработке они могут быть разными.
В продуктовой компании исходят из того, что проект обычно не на один месяц, можно работать с техническим долгом и всё такое. И здесь нужно, например, сделать более переиспользуемое, более качественное решение — и перед этим посмотреть, можно ли использовать что-то из того, что уже сделано. Добавление любого нового — это достаточно ответственное решение. Здесь не предполагается, что именно джуниор добавит в первые месяцы работы что-то новое в продукт, что будет потом использоваться несколько лет.
В заказной разработке вполне может быть наоборот. Возможно, что проще будет быстро сделать форму с нуля, а не изобретать какой-то суперкомпонент, который станет в будущем все формы поддерживать. У вас либо уже есть решение, которое вы переиспользуете среди всех проектов, либо это код с нуля, который просто решает задачу здесь и сейчас, а что будет с ним потом — вообще некритично.
Сеньоры, вам слово
Поделитесь в комментариях своим опытом с начинающими коллегами, как им лучше поступать в разных ситуациях, как быстро вкатиться в новый проект и с какой фронтенд-реальностью вы столкнулись на последнем месте работы.
