Масштабирование iOS-приложений: Как это делал Рамблер?
Сегодня наш собеседник — Егор Толстой, руководитель отдела iOS-разработки в Rambler&Co, организатор и постоянный спикер практически-раз-в-двухмесячного митапа Rambler.iOS. Помимо работы над такими приложениями, как Рамблер.Почта, Рамблер.Новости и LiveJournal, много времени уделяет opensource проектам, в частности Typhoon — уже около года является активным участником сообщества и одним из основных контрибьюторов. В общем, нам вновь есть, о чём поговорить.
— Добрый день. Расскажите коротко о себе.
— Привет. Меня зовут Егор, недавно я стал руководителем iOS отдела в компании Rambler&Co. Выпускник факультета Радиоэлектроники Московского Авиационного института. Ещё курсе на третьем занялся мобильной разработкой, поэтому после окончания университете решил не идти по стезе защиты информации и дальше продолжил разработку под iOS.
В Rambler&Co пришёл два года назад, до этого работал в небольшой аутсорсинговой компании. Помимо основной работы, много времени уделяю участию в жизни сообщества — статьи, выступления на конференциях, open source проекты. Организую раз-в-двух-месячный митап Rambler.iOS, и пытаюсь постоянно там выступать сам. Вот, кстати, в конце поста будет видео, как в последний раз я плакался про то, как сложно делать нормальную пагинацию в мобильных приложениях. Еще веду свой небольшой блог.
— Вы занимаетесь iOS-разработкой в Rambler&Co. Когда вы пришли, какие цели перед вами стояли?
— Когда я пришёл сюда два года назад, у нас был небольшой отдел мобильной разработки, Четверо iOS-ников и парочка Android-щиков. На тот момент все сидели вместе, был у нас один руководитель мобильной разработки и в основном всё, что мы делали, это поддерживали legacy код старых мобильных приложений. Они были реально старые, код писался в каких-то бородатых годах и там была полная жуть. Чуть позже в Рамблере было сформировано отдельное структурное подразделение под названием Rambler Digital Solutions, в которое вошли все технари. У него матричная структура, то есть всё разделено на несколько отделов. И с тех пор всё стало гораздо лучше.
В тот момент к нам пришёл мой бывший руководитель Герман Сапрыкин, с которым мы когда-то начинали работать над проектом Рамблер.Почта. Как раз при нём у нас всё пошло на поправку и мы начали налаживать процессы разработки. Достаточно расплывчатое определение, которое включает в себя кучу всяких разных вещей: стандарты разработки, взаимодействие в команде, code review, continuous integration, continuous delivery, обмен знаниями — и прочее в том же духе. В том числе мы внедрили практику unit-тестирования и более того — на некоторых проектах мы адаптировали TDD, в основном при разработке сервисного слоя. И отдел начал лавинообразно расти.
В тот момент мы перестали поддерживать старые проекты. Все усилия были направлены на написание новых продуктов. Я тогда занимался Рамблер.Почтой, первый релиз было год назад. Это как раз оказалось показателем того, насколько хорошо и качественно у нас стало получаться делать мобильные приложения. Казалось бы почтовая программа, сложный продукт, куча логики, но на старте у нас был crash-free в районе 99,9%. Это очень хороший результат.
Сейчас мы находимся в состоянии постоянного развития, налаживаем различные рабочие процессы, в том числе Сontinuous Delivery. Мы ещё активно работаем над Dashboard состояния проектов. В отделе будет висеть большая плазма, на которой будут выведены статистики по всем проектам: сколько unit-тестов, сколько crash-free и всё в этом духе.
Одной из важных вех в развитии команды стало принятие единых архитектурных стандартов для всех разрабатываемых приложений. Во-первых, это использование n-tier архитектуры, чаще всего состоящей из двух слоев: presentation — все, связанное с отображением конкретных экранов, и business logic — независимая бизнес логика, в которую входят работа с сетью, кеширование данных, механизмы синхронизации.
Копнём чуть глубже. Вместо стандартного MVC на уровне Presentation мы используем архитектурный подход VIPER, позволяющий добиться максимальной модульности, тестируемости и переиспользуемости компонентов экранов. VIPER, к слову, вообще практически родная для нас тема. За время его использования мы написали кучу статей и компонентов для работы с ним. Ну и, конечно, заспамили конференции. Как метко подметил мой коллега Сергей Крапивенский, мы похожи на Ласковый Май — тоже одновременно в разных концах России выступаем с одной темой (а вот, кстати, его выступление на CodeFest 2016.codefest.ru/lecture/1084). Для построения слоя бизнес-логики мы используем модель SOA, разделяя его на независимые сервисы, работающие с одной бизнес-сущностью.
Сейчас у нас в отделе 25 человек. Помимо рабочих проектов много времени уделяем различным Open source вещам. Например, есть у нас такой популярный кодогенератор, который мы писали для себя, потом решили заопенсорсить и вроде как в народ зашёл. Кроме этого часто участвуем в различных конференциях. Как раз год назад стали проводить свои митапы, а после этого нас начали приглашать на более крупные конференции (таких как, собственно, Mobius). Мы продолжаем набирать новых сотрудников, у нас есть новые проекты и новые задачи.
Ну и, конечно, за время работы в Rambler&Co я успел поучаствовать в нескольких интересных проектах: Рамблер.Почта, Рамблер.Новости и еще не вышедший в продакшн LiveJournal. Были, конечно, и печальные моменты — к примеру, разработка так и не увидевшего свет peer-to-peer геолокационного чата, о котором ч до сих пор вспоминаю и всплакиваю — вложил в него все сердце.
— Typhoon Framework. Расскажите вкратце о нём? Какую роль вы играете в его разработке?
— Typhoon — это самый популярный и часто используемый DI-контейнер для Objective-C. Первая версия у него вышла года три назад. Это цемент, который связывает вместе все компоненты наших приложений. Typhoon встраивается в наше приложение и она позволяет вынести конфигурацию всех зависимостей, создание всех объектов, инициализацию графа зависимостей куда-то на более высокий уровень. Это позволяет декомпозировать модули нашего приложения. Все компоненты становятся максимально независимыми, ничего не знаю друг о друге и реализуют DI- принцип.
Я влился в команду контрибьюторов Typhoon в прошлом году. Всё началось с того, что я на локальном митапе рассказывал о Typhoon, почему он хорош и почему его надо использовать. После этого я написал на Хабре цикл статей о том [тут бы ссылку на этот цикл, наверное], что такое Typhoon и как он устроен. И в это же время я сам находил какие-то проблемы в Typhoon, сам их правил, отсылал реквесты. И потом меня позвали в основную команду.
Из интересных реализованных мною фич можно выделить поддержку работы с несколькими stpryboard’ами, расширенные механизмы активации контейнера и переработку логики использования конфигов. Сейчас я заканчиваю крупную задачу — добавление специальных TyphoonStoryboardDefinition, которые позволят работать с контроллерами, создаваемыми из storyboard так же, как и с любыми другими объектами. К примеру, можно будет управлять их жизненным циклом.
Сейчас мы активно готовимся к выходу версии 4.0 с поддержкой нового крутого синтаксиса и отдельного проекта для работы со swift. В настоящее время синтаксис у Typhoon очень сложный и громоздкий, а должно всё стать проще и нативнее. Порог вхождения уменьшится.
Работа с Typhoon дала сильный толчок моему развитию как специалиста — это очень крупный проект, в котором собрано огромное количество интересных и необычных технических решений. Кроме того, над ним вплотную трудится команда сильных разработчиков — наш соотечественник Алексей Гарбарев, программист с n-летним стажем Jasper Blues и уже упомянутый мной Герман Сапрыкин. Ребята не только помогали мне разобраться в логике работы фреймворка, но и просто подключали к разным техническим и архитектурным дискуссиям, которые во многом повлияли на мои взгляды на разработку.
Обращусь к коллегам из мира iOS разработки — выделите хотя бы несколько часов в неделю на работу над open source проектом. Это приносит пользу не только сообществу, но и вам. И Typhoon на рода такого проекта отлично подходит, сейчас у нас открыто около 30 Issues.
— Расскажите об особенностях Typhoon Framework (автоинъекции и т.д.)
— Во-первых, Typhoon крут тем, что основная команда, которая разрабатывает его, начала его делать под свои нужды. В основное время они занимаются довольно крупными проектами для разных заказчиков. И они понимают, что им на самом деле нужно, и фреймворк они изначально делали под себя.
Именно поэтому Тайфун по сути это не просто примитивный DI-контейнер, он позволяет пользователю работать с множеством разных фишек. К примеру, это Typhoon-конфиги. Вы можем вносить данные в конфиги и они могут инжектится в наши объекты так же, ка и любые другие зависимости. Это может быть полезно для приложений конструкторов. У нас это, например, Рамблер.Касса.
Например, в регионах не удобно пользоваться всем приложением Рамблер.Касса и они могут заказать себе брендированное приложение. У нас есть общее приложение-контейнер, из которого мы автоматически на лету собираем брендированные версии, меняя конфиги, где объявлены цветовые схемы, данные API и всё в таком духе.
Много интересного так же в Typhoon есть для организации тестирования.
На самом деле, лучше всего за меня расскажет цикл моих статей на Хабре про работу с Typhoon — начиная от общего знакомства и заканчивая как раз перечислением его интересных особенностей.
— Давайте поговорим об масштабировании iOS-приложений для, собственно, приложений Рамблер. Как у вас это было реализовано?
— Если говорить про масштабирование разработки, то здесь всё интересно. Как я и говорил, у нас команда из 25 человек. В других компаний программисты разбиты по продуктовым командам. Ты приходишь работать, например, не в мейл.ру, а в команду мейл.ру поиска. Ты работаешь в небольшом отделе и с другими iOS-никами можешь никогда и не увидится. Максимум общий чат. Соответственно у каждой команды свой стек технологий, свои процессы, свои подходы к разработки. И командный опыт циркулирует только в рамках этой команды.
У нас всё по-другому. Мы все сидим рядом и работаем в одном отделе и у нас распространена ротация между проектами. Понятное дело, что стороны бизнеса это, конечно, проблема. У него есть своя команда, которая делает проект, и они понимают, что смена разработчика может повлечь за собой ошибки и потерю времени. Перед нами стояла задача использовать универсальные задачи и универсальные подходы, чтобы переход между проектами ни на чём не сказывался]. Большую роль в этом сыграл единый подход к архитектуре приложений. Мы договорились, что приложение делится на несколько слоёв и описали общие подходы к архитектуре каждого слоя. Благодаря тому, что все наши приложения достаточно похожи, это помогает новому человеку легко влиться в процесс. Кроме того мы активно ведём подробную техническую документацию всех проектов.
— Почему вы используете Typhoon, а не «изобретаете свой велосипед»?
— У меня на эту тему будет отдельный слайд в моём выступлении. Есть секция, в которой я рассказываю легенды и мифы о Тайфуне. Один из мифов как раз о том, что можно написать свой фреймворк. Что я могу на это сказать. Typhoon очень сильно уменьшает количество и сложность кода, отвечающего за создание графов объектов и передачу зависимостей при навигации между экранами. Он даёт нам централизованное управление зависимостями без недостатков своего «велосипеда». Свой «велосипед» это почти всегда какой-то сервис-локатор. Проблемы их известны и о них написана куча статей. Интеграция Typhoon в проект очень проста и в нём реализовано всё, что может понадобится и даже больше.
Мы не видим ничего проблемного или опасного в использовании сторонних компонентов, особенно прошедших проверку сообществом и временем. То время, которое мы могли бы потратить на написание своего велосипеда, лучше направить на что-то действительно полезное. Скажем, организацию очередного Rambler.iOS или реализацию новой фичи в Генерамбе.
— О чём будет в итоге ваш доклад на Mobius 4 июня?
— Около года назад я уже рассказывал про Typhoon. После этого и я, и другие ребята из нашей команды упоминали его в своих выступлениях. К сожалению, это повлекло за собой небольшой локальный хайп — многие из наших гостей стали встраивать его в свои проекты, не до конца понимая, какую конкретно пользу он может им принести. У кого-то это вызывало разочарование в духе «я же то же самое могу написать руками в пять строк», у кого-то — хаос в коде.
В этот раз я хочу рассказать несколько о другом — моё выступление крутится не вокруг устройства Typhoon и его синтаксиса, а вокруг конкретных юз-кейсов, в которых он тем или иным образом помогает. Что-то вроде набора небольших историй вида «проблема→способ решения→Typhoon». Я надеюсь, что через призму этих примеров они увидят свои реальные задачи и смогут сделать осознанный выбор — нужен им Typhoon или нет.
Обещанное видео о правильной пагинации:
