Country not specified
Unknown website Share

Apps4all

Страна: -
Город: -
Был онлайн: -
О себе:
 
08-07-2016, 10:56
Apps4all

Герман Сапрыкин (Rambler&Co): «Не забывайте основные принципы для всех разработчиков - KISS и SOLID»

​С редакцией Apps4All поделился своим опытом Герман Сапрыкин, спроектировавший основные аспекты архитектуры всех мобильных приложений Rambler&Co — он рассказал в интервью о том, какие стадии проходит задача от идеи до продакшна, как со временем менялись взгляды команды на правильное строение слоя бизнес-логики приложения и какие решения использовали.

Герман, добрый день. Расскажите немного о себе: как попали в mobile? Какова зона вашей ответственности в Rambler&Co?

Мне удалось приобрести себе новый iPad 2 через несколько месяцев после их выхода в Америке. Тогда, еще студентом, я стал фанатом яблочных устройств. С середины 5 курса я начал заниматься разработкой для iOS под руководством преподавателя из университета, который работал в этой сфере профессионально.

В настоящее время отвечаю за развитие и техническую часть iOS и WP разработки в Rambler Digital Solutions.

Немного о процессе разработки в вашей мобильной команде: какие стадии проходит задача от идеи до продакшна?

Rambler Digital Solutions является центром разработки холдинга Rambler&Co. К нам приходят другие подразделения холдинга с заказами и идеями для своих продуктов. Под каждый проект мы выделяем людей и формируем команду, в которую входят с нашей стороны: пм, аналитики, дизайнеры, веб и мобильные разработчики, а со стороны заказчика - продуктологи. Поэтому процесс сильно зависит от проекта: разные заказчики, разные сложности проектов. Но всегда на вход мобильной команды должны поступить документация и дизайн. В конце разработки обязательно производится тестирование, а далее, да, уже продакшн.

Как со временем менялись ваши взгляды на правильное строение слоя бизнес-логики приложения?

Мне очень повезло с командой. Наши взгляды на разработку не только сошлись, но и синхронно менялись на протяжении работы вместе. Начинался наш путь с пяти проектов, каждый из которых был написан по-своему. Благодаря такому разнообразию мы получили хороший материал для анализа, опыт того, как делать не стоит. Первые попытки поиска пути произошли под влиянием WWDC, на котором Apple продемонстрировал свой вариант ухода от massive view controller. Apple выделил datasource для экранов в отдельные объекты, которые все равно превратились в god-object. Этот подход до сих пор хорошо работает в одном из проектов, но таких изменений нам показалось недостаточно. Следующим этапом стало освоение service oriented architecture. С ее помощью мы написали несколько крупных проектов, но столкнулись с другими проблемами. Первая - отсутствие правил написания view controller, в результате на разных проектах мы имели совершенно разную архитектуру экранов. Второй проблемой для нас стало покрытие проекта тестами: если сервисы покрывались без проблем, то, опять же, с контроллерами были сплошные вопросы. Поэтому мы начали изучать и использовать VIPER.

Какие решения вы использовали и на чем в итоге остановились?

По ходу наших поисков мы попробовали MVVM, MVC, FRP и VIPER. Последний оказался для нас самым подходящим решением. Мы его немного модифицировали, объединив с SOA. И кстати, 22 декабря мы устраиваем митап ​Rambler.iOS, посвященный нашему варианту VIPER. На самом деле, взгляды меняются всегда. Постепенное улучшение небольшими этапами - это то, к чему мы стремимся вместе с командой. Не сказал бы, что “остановились” - верное слово в данном контексте, потому что у нас есть множество мыслей и планов относительно дальнейшего пути развития.

Расскажу о текущем варианте построения мобильных приложений.

Мы разделили приложение на две части - бизнес-логика и пользовательский интерфейс. Это позволяет сразу разделить работы на непересекающиеся части, сводя проблему merge-hell к минимуму. Каждая часть пишется по своим правилам.

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

Сервисы, слой бизнес-логики, пишутся в двух вариантах. Простой и сложный. Под простым понимаем наличие единственного сервера, единого протокола работы с сервером или небольшой и быстрый проект. В этом случае сервисы представляют собой классы, которые реализуют в себе всю бизнес-логику через вспомогательные объекты - сетевые клиенты, парсеры, валидаторы, мапперы и другие. Примером такого подхода является приложения Афиши, Рамблер.Новостей.

Под сложным - множество серверов, разные форматы общения, “вечноживущий” проект, сложные правила синхронизации, повышенные требования к гибкости работы с сервером. В таких проектах наш простой способ написания сервисов начал давать сбои, поэтому мы стали использовать более модульные сервисы. Модульность достигается за счет инкапсуляции логики в операциях и создания цепочек операций. Она не дается бесплатно, приходится писать в разы больше кода, поэтому в “простых” проектах избегаем такого подхода. Этот вариант мы развивали на проекте Рамблер.Почта.

Конечно, дьявол кроется в мелочах, обо всем в одном интервью не рассказать, поэтому с начала 2015 года мы организуем встречи Rambler.iOS, на которых рассказываем о наших методах разработки.

Как проходит процесс тестирования мобильных приложений? 

В конце каждого этапа разработки проходит тестирование наших приложений. В то время, пока мы еще заняты написанием кода, отдел QA составляет тест-планы, по которым и проверяют результат нашей работы. Тестирование проводится на различных устройствах и версиях iOS, у нас довольно обширный парк - 30+ девайсов. Проблемы? Явных проблем не помню. Есть обычные вопросы во взаимодействии команды разработки и команды тестирования: не все внесли в changelog или что считать багом, а что фичей.

Какие инструменты используете при тестировании?

Инструменты тестирования довольно стандартные - используем CI на Jenkins, TDD на XCTest. Наша команда проделала огромную работу по улучшению качества кода и проектов, но многие вещи пока еще остаются в планах. Например, одним из следующих этапов станет использование на CI не только симуляторов, но и реальных устройств. Конечно, пробовали и UI-тестирование, но пока это направление у нас не прижилось.

Используете ли сервисы облачного тестирования? 

Нет, не используем.

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

В мобильной разработке много молодых и горячих ребят, которых периодически надо тормозить :).

Немного об аналитике приложений: какая у вас система аналитики приложения? 

В наших приложениях используются различные системы. Мы используем обертки, которые позволяют подключать/отключать аналитики достаточно быстро. Для разработчиков основное - Fabriс. Все необходимые технические метрики снимаются именно с него.

Можете выделить тренды в мобильной разработке этого года и прогноз на 2016?

При текущих ценах на российском рынке прогнозировать ничего не хочется :).

Дайте совет разработчикам мобильных приложений

Не забывать основные принципы для всех разработчиков - KISS и SOLID.

Можете назвать свой топ приложений по частоте использования и еще несколько примеров клевых приложений, которые вам нравятся с точки зрения их реализации или идеи?

  • Рамблер.Новости
  • Feedly
  • Evernote
  • HH
  • Первая любовь - Flipboard для iPad.

Герман, благодарю за интересное интервью! 

Напоминаем читателям, что 22 декабря пройдет митап Rambler.iOS, посвященный нашему варианту VIPER. Организаторы приглашают всех желающих https://rambler-digital-solutions.timepad.ru/even...

 
архитектура
приложения
тестирование
rambler
интервью
разработчикам
0 0 0

Чтобы оставлять комментарии вам необходимо зарегистрироваться