Как освоить мобильную разработку и построить BDUI-архитектуру Маркета

Старший разработчик мобильных приложений Яндекса

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

Дмитрий, расскажите, как вы пришли в мобильную разработку, и чем ваш путь отличается от классического iOS-разработчика?

По образованию я инженер путей сообщения, но школьное образование получил в Лицее информационных технологий. Там уделялось большое внимание техническим знаниям — я с первого класса обучался программированию, ездил на олимпиады по математике, участвовал в конференциях. Во время учебы в университете я продолжил принимать участие в соревнованиях по программированию, занимая высшие места среди технических вузов. Окончив университет и отработав по специальности полгода, я понял, что работа по специальности меня не привлекает. И я решил использовать свой обширный технический бэкграунд, чтобы переквалифицироваться в разработчика. У меня было много практических знаний, чтобы получить теоретическую базу, я прочитал книгу «Философия Java». После этого я составил резюме — и меня позвала на работу небольшая новосибирская студия Academ Media. На тот момент в студии не хватало разработчиков приложений под экосистему Apple, и мне предложили занять эту должность. Хотя на тот момент я знал об iOS и MacOS не так много, я решил рискнуть и согласился. Благодаря моему бэкграунду и интересу к технологиям мне удалось быстро получить необходимые навыки и переквалифицироваться в разработчика приложений для экосистемы Apple. Вообще нужно сказать, что мое непрофильное образование мне пригодилось. Инженер путей сообщения составляет графики движения поездов, инструкции по маневровым работам, инструкции по сортировке поездов и другие документы с алгоритмами, регламентирующими работу станций. Я делаю примерно то же самое, но с программами — проектирую, рассчитываю, управляю. Но, конечно, мой путь нельзя назвать обычным — все-таки, большинство разработчиков получают профессию целенаправленно. Сейчас я в профессии уже около 10 лет и успел поработать и с небольшими студиями, и с крупными корпорациями — например, Тинькофф, Тензор и Яндекс. А также я работал преподавателем на онлайн-курсе по iOS-разработке.

Какими были ваши ключевые проекты в Яндексе?

Одним из моих ключевых проектов в Яндексе стал перенос главного экрана Яндекс.Маркета на BDUI-технологию. Это заняло 3-4 месяца. Мне пришлось работать как с нативным кодом, так и с бэкендной частью на Kotlin. Это также потребовало изучения нового языка, новой технологии и окружения, а также координации с менеджерами, дизайнерами и другими бэкендерами. Также я внедрил ленту рекомендаций Яндекс Маркета, выделив ее в отдельный SDK — мы вынесли туда часть нативного кода, связанного с основной секцией ленты. Задача заключалась в том, чтобы сделать компонент независимым от кода Маркета. После этого наша команда помогала интегрировать ленту в другие приложения Яндекса — например, пользователь видел рекомендации товаров во время заказа такси. Также мы выполнили ряд работ на мобильном бэкенде: выделили отдельный эндпоинт и поверх существующего маппера написали новый, который учитывает кейсы других приложений. Задачи затронули множество сервисов и команд — разработчиков фреймворков и инфраструктуры, специалистов по безопасности, ответственных за предоставление ресурсов. Также нужно было постоянно проходить ревью. Нативный фреймворк и инфраструктура для бэкенда находились в зачаточном состоянии, и некоторые нужные функции отсутствовали, поэтому приходилось нарабатывать экспертизу в процессе и думать над новыми решениями задач.

Расскажите подробнее о переводе главного экрана Яндекс.Маркета на BDUI — как внедрение этой технологии изменило архитектурный подход к мобильному приложению, и какие инженерные вызовы пришлось решить при интеграции с бэкендом?

BDUI-архитектура позволяет серверу управлять не только бэкенд-частью, но и формировать интерфейс. Маркетплейс идеально подходит для реализации этой архитектуры, так как он всегда должен быть up-to-date: отражать актуальные цены, наличие товаров, способы и время доставки, последние отзывы и т.д. Главная метрика маркетплейса — GMV (Gross Market Value, суммарная выручка), и для ее увеличения все изменения должны проходить через A/B-тестирование. А BDUI отлично подходит для проведения большого количества тестов в сжатые сроки. До внедрения BDUI у нас был очень большой time to market, потому что любое продуктовое решение требовало нативного кода — а релиз происходил раз в неделю и часто сдвигался по разным причинам. В разработке приложения было задействовано около 100 специалистов — соответственно, каждый день в кодовую базу вносилось множество изменений, которые часто конфликтовали. Однажды мы не могли зарелизить приложение месяц, потому что каждый раз находили ошибки. Еще одной сложностью было большое количество A/B-экспериментов, которые проводили продакт-менеджеры. Эксперименты — неотъемлемая часть развития маркетплейсов, но каждый из них требует времени на реализацию и тестирования. Все эти факторы привели к идее, что BDUI-технология — лучшее решение для нашего маркетплейса. Сначала технологию протестировали, а затем отдали моей команде для полноценной реализации. Мы заново создали главную страницу на BDUI и MAPI v1, разработали ленту, контент-поиск, хот линки — по сути, мы полностью сделали новый главный экран по актуальным продуктовым требованиям. Кроме ускорившегося TTM, нам удалось также добиться консистентности и компактности в дизайне. Главной сложностью проекта было то, что у мобильных разработчиков не было опыта написания backend-частей — пришлось учиться это делать. Также главный экран был одним из самых высоконагруженных участков, и нужно было сохранить его стабильность. Я самостоятельно решал вопросы доступа между внутренними сетями, согласовывал API-контракты между сервисами, договаривался о нагрузке с другими командами, которые отвечали за backend и ресурсы. Когда мы начали переносить экран, сам движок мобильного бэкенда еще не был полностью готов — нам пришлось дописывать его, проходить архитектурные ревью и согласовывать изменения с инфраструктурной командой. Для описания UI мы использовали open-source библиотеку DivKit&, но ее возможностей тоже не всегда хватало, и мы контрибьютировали в саму библиотеку, добавляя нужные фичи. Я фактически держал проект на себе: писал почти весь код, координировал работу и распределял задачи. Также я проявил себя при переговорах — мне удалось договориться практически со всеми подразделениями, чтобы работа прошла слаженно. Всё это позволило мне кратно вырасти как специалисту и получить позицию техлида.

Как вы структурируете процесс погружения в незнакомые системы и находите решения, работая в проектах с неизвестным кодом и новыми технологиями?

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

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

Я знаю, что также вы с нуля разработали один из самых сложных проектов в компании — микросервисы для Яндекс.Маркета. Расскажите об этом подробнее.

Да, разбивка мобильного бэкенда Яндекс.Маркета на микросервисы была важным проектом — я с нуля поднял инфраструктуру и настроил пайплайны для релиза двух новых микросервисов: для сетевых походов и для сборки верстки. Поводом, опять же, послужило длительное Time to Market. Множество специалистов работали с одной базой, где скапливалось большое количество багов — в день доходило до 200 коммитов. Развивать приложение в таких условиях было очень сложно. Поэтому мы решили разбить бэкенд на микросервисы, каждый из которых нес ответственность за свою группу экранов. Это была сложная работа из-за отсутствия полной и актуальной документации, что требовало постоянного изучения кода, коммуникации с другими командами и получения различных прав доступа. Мне пришлось освоить роль DevOps, хотя я никогда этим не занимался ранее. Но в итоге все получилось. Так как в приложении планировалась большая нагрузка, необходимо было настроить систему мониторингов и алертов и создать для них дашборды. В итоге, мы создали дашборды для отслеживания ошибок во всех элементах приложения, загрузки ресурсов и таймингов. А алерты автоматически наблюдали за метриками и сообщали в чат, если какие-либо показатели отклонялись от нормы.