Привет, Хабр! Меня зовут Андрей. 7 лет я разрабатываю под Android, последние полтора года в Альфа-Банке. На проекте мы используем RX Java, но планируем перейти на корутины, основная архитектура MVP, сейчас переходим на MVI. Для внедрения зависимостей используем Dagger, Forking Workflow.
Я считаю свою команду лучшей: когда кодишь в Платежах и переводах, твоей фичей точно пользуются все клиенты, да и темп прокачки в финтехе высокий. Моя команда разрабатывает функционал переводов за рубеж, а я на проекте отвечаю за Android.
Первые шаги мобильного разработчика в бэкенде
Год назад я писал код для мобильного приложения банка и особо не задумывался о переходе на другие задачи. В один прекрасный день мне прилетела таска — добавить параметр в диплинк на Андроиде. Потом меня попросили добавить его ещё и на бэке.
Мы катим фичи без релизов, так как используем BDUI. Здесь статья, где мой техлид подробно расписал, что это такое. Если коротко — наши бэкендеры загружены сильнее обычного, потому что при разработке фичи бэк присылает полностью готовые данные, по которым приложение отрисовывает UI-часть и логику. Я занимаюсь разработкой JSON-ов, чтобы бэкендер понимал, какой респонс ему нужно прислать для Android.
В этот раз наш джавист Марина предложила мне добавить параметр самому. Показала и рассказала, что да как, я сел и сделал в Android Studio. Закоммитил, запушил, проверил — всё работает. Ребята даже в шутку предложили мне перейти в бэкендеры из Андроида. Тут я задумался, а шутка ли это, челлендж показался мне интересным.
Расскажу о своих экспериментах с бэком в формате дневника — вдруг вы решите повторить мой опыт или поделитесь, как проходили этот путь сами.
День первый: как я вообще пришёл к бэкенду
Сегодня я вышел из отпуска и увидел, как мой техлид Аня отправила сообщение команде, что мы можем помогать бэкендерам. На первом же дейлике мне дают задачу по доработке бэка. Джавист Марина объясняет мне, что нужно делать и где взять похожий пример (спасибо ей большое), прошу её сильно не спойлерить, так как самому интересно разобраться, что там к чему. Дейлик заканчивается.
Я иду на общую встречу Андроид-разработчиков, где мы обсуждаем развитие экспертизы в банке, и параллельно скачиваю среду разработки бэка IntelliJ IDEA. Подтягиваю проекты по сброшенным мне ссылкам и берусь за работу. Так как в рассказах Марины было много информации, нужный класс для примера пришлось искать по изменениями с помощью Git-a.
Когда, как мне показалось, я всё сделал, выяснилось, что для запуска тестов нужно поставить Docker, так как в тестах используется библиотека Testcontainers для запуска различной инфраструктуры (MongoDB, Redis, Elasticsearch и т.д.).
При билде проекта прогоняются все тесты. При прогонке отдельного теста билдится проект, если в проекте что-то не так, тест не отработает.
Из необычного — мне нужно было понять, что Properties — это модельки, которые тянут данные в .yml-конфигах, и разобраться, для чего вообще нужна аннотация @ConfigurationProperties.Тут не буду описывать — оставлю вам ссылку, чтобы вы могли почитать, если вам тоже интересно.
На старте мне понравилось: нетривиальные задачи, изучение чего-то нового и интересного. На первый взгляд подход к написанию кода у бэкендеров не такой строгий, как у нас. В целом день прошёл отлично, я рад, что всё получилось.
День второй: первый пул-реквест
Что-то стало более понятным, а что-то наоборот, казалось какой-то магией. Я научился собирать билды на Jenkins, разворачивать микросервисы в Kubernetes (правда у нас самописная ci/cd платформа для этого) и проверять работу эндпоинта с помощью терминала одного из подсов! Открыл свой первый ПР на бэкенде, попросил ребят набросать комментариев, получил 6 апрувов и 8 комментариев от одного разработчика.
Вторая неделя: меня затянуло
На самом деле прошло уже больше двух недель, так погрузился в работу, что забыл написать, что происходит. В целом некоторые вещи стали понятны, в других по-прежнему ощущаю себя человеком, который мало осознает, что происходит. Приходится постоянно декомпозировать и изучать, что и как работает.
Третья неделя: задачи с эндпоинтами и микросервисами
Могу отметить, что всё происходящее непривычно для мозга Андроид-разработчика. Хотя на бэке, как и на Андроиде, у нас Kotlin, но взаимодействие между компонентами отличается. Нет привычных презентеров/вью моделей, роутеров, но есть похожий клиент (для взаимодействия между апишками).
Очень быстро проходит время, так как нет рутинной работы, и ты постоянно разбираешься в чём-то интересном. Из минусов — иногда не замечаешь, как начинаешь перерабатывать.
Я научился создавать эндпоинты, использовать интерцепторы, написал несколько юнит-тестов, интеграционный тест с использованием WireMock. Последнее сложно для понимания, так как на Андроиде у нас такого нет. Но за то, что я справился, меня похвалили.
Из трудностей — в нашей команде я один Андроид-разработчик, и приходится отвлекаться на Андроид-разработку (в основном это спайки: проверить, как на данный момент работает многошаг или функциональность внутри него). Вот здесь можно почитать подробнее, как работают динамические поля в нашем приложении, если интересно.
Я уже выполнил две средненьких задачки. Первая задача — добавить эндпоинт, который возвращает фронту условия перевода. Вторая — сходить из одного микросервиса за комиссией по переводу и вернуть результат так, чтобы его было удобно использовать другому разработчику, когда он будет делать другую фичу, где нужна комиссия.
Первая задача показалась более простой, со второй пришлось посидеть с WireMock, узнать, что это вообще такое, и написать тест, так как фича была новой, и места, куда её будут встраивать, ещё нет.
Четвёртая неделя: штурмую контракты
Мне доверили задачку побольше. Мы изучали и обсуждали контракт взаимодействия апишек с системным аналитиком. Я написал сервис, клиента, добавил проперти, конфиг к ним, добавил к клиенту базовую авторизацию. Поверхностно познакомился с WSDL, показалась очень страшной технологией, но так обычно со всем до момента, пока не погрузишься. Это сервис для передачи данных между микросервисами на языке XML, Андроид-разработчику он не пригождается.
Пятая неделя: боль и страдания
После этого на работе смешались люди, кони, бэк, Андроид, сроки начали гореть и подгорать. На Андроид легко переключиться, на бэк вернуться сложнее. Сейчас пока что я снова фуллстек-девелопер.
Что дальше: забросил ли я бэк?
Сейчас в начале двухнедельного спринта мы решаем с командой, сколько задач я могу взять, чтобы помочь бэкендерам, а сколько продолжу делать в Андроиде. Получается, на неделе у меня несколько задач на разных платформах и один день в неделю на техтаски (у нас нет платформенной команды, поэтому 20% времени мы улучшаем проект: доработки, рефакторинг и разные другие штуки).
К Андроиду я возвращаюсь легко, так как набил руку, а вот на бэке нужно вспоминать, что я вообще делал и как оно всё работает, так как опыта у меня пока маловато.
В планах на ближайшее время научиться смотреть логи для работающих эндпоинтов в Kibana и удаленно дебажить микросервисы. Могу сказать, что новая технология и работа с новой платформой остаются интересными для меня.
О выгорании пока не думаю, мне наоборот нравится чувствовать себя новичком. Опять же команда с пониманием отнеслась к моему обучению. Сначала даже хвалили, но сейчас времени на рефлексию меньше, так как сроки горят у всех, не только у меня. Бэку приятно, что я могу что-то поделать из их задач, пока все счастливы.
Что посоветую тем, кто изучает что-то новое
Всем рекомендую пробовать что-то новое независимо от результата, который можно получить. Лучше жалеть о том, что сделал, чем о том, что не сделал.
Учитывайте свою загрузку: есть ли у вас время на развитие, где искать резервы, когда конкретно осваивать новые навыки, а главное — делать это регулярно. Я изучаю новую платформу, и это помогает команде закрыть проект, поэтому мы заранее планируем время на мои новые задачи в спринте. Если у вас по-другому, нужно понимать, где взять это время.
Вам точно будет нужна мотивация.
У меня с этим проще: я меняю профиль в рамках одного продукта, то есть делаю одну и ту же фичу и с бэкендерами, и как Андроид-разработчик. Команда поощряет моё развитие. Если вы меняете специализацию, нужно подумать, как поддерживать в себе огонь.
Вам будет намного проще с наставником или лидом, который поддержит вас в вашем рвении. Мне изучать бэкенд помогали Миша и Марина — разработчики нашей команды. Я понял, что команда Платежей и переводов абсолютно не зря выбрала Марину лучшим сотрудником. Такое наставничество занимает ценное время и требует терпения и навыков доносить материал. Если вы придёте в backend-разработку Альфы, вы можете встретить Марину на техинтервью.
Будьте более гибкими. В продуктовой команде нужно не только развиваться, но и помнить про задачи бизнеса. Если загорятся сроки на продукте, вам нужно будет переключиться и на время отложить саморазвитие.
На этом всё. Вы точно сможете увидеть в следующих статьях в моём профиле — изучил ли я бэкенд или сгорел на проектах. Возможно, я выпущу статья в духе «Есть ли жизнь после выгорания».
Пишите в комментарии, что бы вы сами хотели изучить, или задавайте вопросы по первым шагам в бэкенде, если тоже интересуетесь этим.
