Comments 12
я делаю Android-приложения в Doubletapp. Полтора года назад мы начали работать над приложением «Яндекс Путешествий»
То есть яндекс не сам пишет свои приложения? Кому принадлежат права?
Почти все большие компании пользуются услугами внешних подрядчиков в разных форматах. Все права принадлежат заказчику, разумеется.
Интересно, приложение на маркете опубликовано от имени "Intertech Services AG". В инете пишут, что "Приложения "Яндекса" в Google App Store ещё в марте 2022-го разделились на две части. В одной разработчиком, как и раньше, указана компания "Яндекс", а в другой — Intertech Services AG."
А пишет приложения кто-то третий. Интересно девки пляшут оказывается.
Зачем народ тогда в яндекс нанимается?
В данном кейсе у нас приложение было написано смешанной командой, а продуктовая часть и бекенд были целиком на стороне клиенте.
Но скоро у нас выйдет подкаст на ютуб-канале Doubletapp с CTO Яндекс Путешествий, в нём мы подробно разобрали то, почему и в каких случаях большие компании пользуются услугами внешних разработчиков.
В данном кейсе у нас приложение было написано смешанной командой, а продуктовая часть и бекенд были целиком на стороне клиенте.
Что такое продуктовая часть и бекенд? Клиент это кто/что (в смысле тонкий клиент или клиент в смысле исполнитель)? Если клиент это исполнитель, то если он писал всё целиком, то что такое смешанная команда?
Надеюсь, на канале вы изъяетесь более понятным языком. Также интересно как выбирается подрядчик. Почему выбрали вашу компанию?
Клиент = наш клиент, тот кто делает заказ, в данном случае Яндекс.Путешествия.
У сложных продуктов есть почти серверная часть, она есть и Путешествий, на ней работает и веб-портал https://travel.yandex.ru/avia/. И есть продукт-менеджеры, которые отвечают за то, как продукт выглядит и работает: какой функционал, какие фичи и т.д.
Смешанная команда: в команде были и наши ребята, и представители Яндекса. Мы начинали проект целиком нашей командой мобильной разработки и тестирования, потом подключили яндексовых тимлидов. И всё происходило в процессах заказчика.
У нас уже был большой опыт работы с разными сервисами Яндекса как с клиентами, мы уже сотрудничали с Путешествиями по другим проектам, доказали компетентность, к нам было доверия со стороны технического руководства, поэтому выбрали нас. В целом в таких случаях для выбора проводится тендер, и рассматриваются факторы опыта, цены, предыдущего опыта, наличие необходимых ресурсов прямо сейчас.
Почему это делают большие компании? Всегда нехватает своих людей, быстро нанять большую качественную команду очень сложно, особенно когда к людям выставляются высокие требования (все участники проекта с нашей стороны проходили собеседование со стороной заказчика на предмет хард скиллов). Также не всегда для экспериментальных продуктов имеет смысл нанимать себе людей, а можно в начале проэкспериментировать силами сторонней команды, а по итогам уже смотреть.
То есть ваша задача была создать интерфейс пользователя для Андроид?
И он получился многомодульным? Сколько примерно разных экранов?
Мы делали мобильные приложения под Android и iOS. Разработку и тестирование мобильной части.
Если интересно ещё про iOS — этой весной прокатили по всем крупным конфам, где была мобильная секция, доклад о том, как мы использовали SwifUI в iOS-приложении Путешествий и какие проблемы с этим были. Можно посмотреть запись https://habr.com/ru/companies/doubletapp/news/740952/
В Android-приложении, на момент написания статьи, ~20 экранов и более 60 модулей
По 3 самописных вьюхи на экран?
Нет, 60 модулей не означает, что они все сделаны для кастомных вьюх. Это и сами фичи, поделенные на несколько модулей, и навигация, и di, и работа с сетью, и вебвью. Сам брендбук разбит на 5-10 модулей по принципу, описанном в статье. На некоторых экранах добавлены несколько кастомных вью, а какие-то требуют из брендбука только цвета и стили текста. Например, на экране с формой поиска требуются вьюшки самой формы и переключалки между режимами, тогда как на экране с информацией о приложении нам нужны только логотип и стиль текста меню
Спасибо за текст
Да, при добавлении новой иконки у нас все еще будут заново собираться
модули всех фичей, но это не будет происходить в каждом тикете. А вот
при условном изменении цвета текста в нашем кастомном тулбаре
пересоберется только одна фича
Кажется, вероятность добавления иконки сильно больше переделки существующего используемого стиля, у вас не так?
Представляется, что если волатильность брендбука начинает влиять на время сборки - нужно сам брендбук делить на несколько. Всё-таки это некая система отсчёта, которая не должна меняться постоянно.
Кажется в действительно большом проекте с общим "брендбуком", с постоянными добавлениями условных иконок в нём, можно заводить раз в квартал модуль для нововведений и также раз в квартал делать чисто технические изменения по переносу накопленного в модуль брендбука. Пересборок будет минимум, ведь новые иконки обычно для новых фич
Спасибо за прочтение)
Тут скорее имеется в виду небольшие изменения в кастомных вью, например, у тулбара был заголовок, а в новой фиче появился еще подзаголовок, и такое у нас случалось довольно часто. Собственно поэтому мы и вынесли компоненты в отдельные модули.
С иконками же поступали следующим образом: дизайнеры шли впереди на 1-2 фичи, и когда разработчик принимался за фичу с еще не добавленными иконками, то автоэкспортом выгружал пачкой все новые иконки. Таким образом, брендбук вызывал только по одной дополнительной пересборке у каждого разработчика на несколько фич.
Если же несколько разработчиков начинали параллельно работать с новыми фичами, в которых есть новые компоненты брендбука, то кто-то один делал экспорт и сразу делал пулл реквест, который мы быстро мержили.
Для реально большого проекта идея с разделением брендбука выглядит рабочей.
Храним краску с умом: как организовать ресурсы в многомодульном проекте