Привет! Меня зовут Павел, я работаю в команде Авито Услуг. Во фронтенде я больше 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
