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

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

Шаг первый: осознал, что пора переходить в бэкенд

Сначала я определил для себя первопричину этого желания. 

Мне нравится работать в неизвестности, постоянно учиться новому. Когда я только пришёл во фронтенд — для меня все задачи были такими, но со временем они превратились в рутину. Я захотел более масштабных задач в плане реализации, продумывания архитектуры, взаимодействия с пользователями и другими командами. На фронтенде не было возможности решать такие задачи, а на бэкенде с ними был явный перевес. Ещё важную роль в решении сыграла моя команда — она очень классная и я не хотел уходить в другую. 

У нас в Авито это нормально — поделать что-то в чужой специальности, если нужно помочь команде. Так я решил попробовать свои силы в бэкенде, понять, как работает смежная область, освоить новые для себя подходы в разработке и прокачать инженерные скиллы. Заодно это помогло бы разгрузить бэкенд-разработчиков в команде и выполнить OKR, которые в большей степени концентрировались на бэкенде.

Шаг второй: получил «благословение» от тимлида и сформулировал цели

Я озвучил своё желание тимлиду, мы обсудили с ним все варианты и риски. Он был не против того, чтобы я выполнял задачи с перевесом в бэкенд и «благословил» меня на это. 

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

• понимать базовые вещи бэкенда: языки, паттерны проектирования;

• понимать контекст задач;

• поговорить с другими командами с чужой функциональностью;

• выяснить все неопределённости для решения задач;

• описать и декомпозировать задачи;

• реализовать их в рамках дедлайнов.

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

Я советую описывать цель более конкретно по системе S.M.A.R.T., например, так:

S — specific, конкретная. Какого именно результата я хочу достичь. Выполнять бэкенд-задачи или иметь высокоуровневое понимание работы приложения.

M — measurable, измеримая. По какому показателю я пойму, что цель достигнута. Защититься на калибровках как бэкенд-инженер или пройти собеседование в %COMPANYNAME% на бэкендера.

A — attainable, достижимая и реалистичная. Хватает ли мне ресурсов, чтобы достичь цели. У меня есть всё рабочее время, плюс я готов посвящать достижению цели часть свободного времени. Команда и компания меня в этом поддерживают и готовы помогать. Поэтому — да.

R — relevant, актуальная. Как моя цель соотносится с глобальными целями компании. Компании нужны универсальные разработчики, которые готовы выполнять задачи в смежных областях. Им буду я.

T — time-bound, ограниченная во времени. Когда именно я хочу прийти к цели. Через полгода.

Шаг третий: изучил основы языка и нашёл ментора

Чтобы понимать, что происходит в коде, нужно понимать основы языка и иметь навык написания простых запросов в базу. У меня был опыт работы с другими языками программирования, поэтому проблем не возникло. За пару недель я перешёл с JavaScript’a и TypeScript’a на Go.

А чтобы быстрее и качественнее вникать в бэкенд, нужно найти ментора или тех, кто готов помогать осваивать новую область. В моём случае это были тимлид, бэкендеры из команды и открытое Go комьюнити в Авито. Всем им за это огромный респект.

Шаг четвёртый: начало практики и посвящение в бэкендеры

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

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

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

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

Также я прошёл посвящение в бекендеры, как же без него :)

По реализации из одной фичи мы всё сделали, протестировали — всё работало. Но когда начали запускаться — сервис упал. Это был очень хитрый кейс, я недосмотрел одну багу. Посвящение в бэкендеры — это классика, обязательно надо уронить сервис или положить базу :) К счастью, это продлилось всего 10 минут, потом я всё пофиксил и поднял сервис.  

Это график работы сервиса, который отдаёт отзывы на карточку объявления. В 19:36 я запустил эксперимент, в 19:37 всё стало ухудшаться. В 19:52 сервис уже работал в штатном режиме.

Результаты и впечатления

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

Самым трудным для меня было приобрести мышление бэкенд-разработчика. Бэкендеры в задачах более высокоуровнево смотрят на вещи, а мне этого не хватало. Вообще это решается просто: надо начать вести себя как бэкендер, проектировать сервисы, защищать их перед коллегами и разрабатывать. Оно плавает как уточка, крякает как уточка, ведёт себя как уточка, значит, это уточка :)

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

Мои планы на будущее

В ближайшие полгода я планирую доосвоить знания в нужных для работы областях:

• базы данных;

• высокоуровневая архитектура;

• Go на продвинутом уровне. 

Планов бросать фронтенд у меня нет. Я и сейчас помогаю команде с небольшими фронтенд-задачами. Если есть ресурсы — не вижу в этом проблем.

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

Что делать, если ваша компания против горизонтальных переходов

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

Если среди коллег не удалось найти ментора — идите в социальные сети, например, LinkedIn. Наверняка там найдётся какой-то проактивный бэкендер, который шарит знание и готов помогать новичкам. Ещё есть сайт по поиску менторов — Solvery. Там можно найти менторов по фронтенду, бэкенду, QA и другим специальностям, не только по разработке. Например, по продакт-менеджменту. 

Чтобы практиковаться — я бы просился делать задачи на бэкенде, хотя бы какие-то маленькие. Но если вы точно решили менять курс, а ваша компания упирается — ищите другую, в которой вы будете на фронтенде, но вам позволят брать задачи с бэкенда и в итоге полностью перейти на него. Например, приходите в Авито :)

Предыдущая статья: Ультимативный гайд по HTTP. HTTP/1.1