Интервью с разработчиком. Александр Блинов (REDMADROBOT)

Друзья, очень рад анонсировать вам новую рубрику — «Интервью с разработчиком».

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

И сегодня мы будем общаться с Александром Блиновым.

Расскажи в двух словах:

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

Я руководитель Android-практики в REDMADROBOT. Свой путь в роботах я начал 2 года назад в качестве лида одного из проектов. В настоящее время я занимаюсь развитием Android-практики в группе компаний.

Какой у тебя опыт? Почему разработка Android?

Android-разработкой я занимаюсь уже более 6 лет. Мое первое приложение поддерживало версию 1.5. Почему именно Android? В университете на доске объявлений висело две вакансии: разработка сайтов на PHP и приложений на Android. Я выбрал второе, так как считал, что за телефонами будущее.

Какие приложения написала твоя команда?

Я работал в трех компаниях: стартапе Mobisters.Mobi и аутсорсе — Arello Mobile и REDMADROBOT. За это время я поучаствовал в десятках проектов: разнообразные редакторы изображений, аудио и видеоредакторы, всевозможные онлайн магазины по заказу еды и продуктов, карты лояльности и личные кабинеты в различных областях деятельности, мобильные рабочие места...

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

Так как это был мой первый опыт программирования, то приложение просто кишело антипаттернами и внутри представляло собой отличную тарелку со спагетти. Тем не менее у него было порядка миллиона скачиваний - не каждый современный продукт может похвастаться такой аудиторией!

Да, достаточно большое количество загрузок. Шикарный результат для первого приложения. А если говорить про текущую команду? Уверен, что для всех приложений вы используете весь опыт. Но если говорить о приложении-фаворите, которое может похвастаться чем-то особенным. Есть ли такое?

Уговорили, расскажу про последнее приложение) Это мобильное рабочее место для работников страховой компании. Существует несколько сценариев визита, каждый из них состоит из последовательности однотипных экранов: сделать фото, показать результат, показать подсказку, заполнить форму и т.п. Мы сделали приложение максимально гибким и полностью отделили логику роутинга и сохранения состояний от логики экранов. Это позволяет безболезненно добавлять новый этап или вообще делать новый визит без изменения имеющихся экранов, максимально их переиспользуя.

Подумываем распространить этот подход для для создания приложений вообще, но эта идея на проработке.

Что является лучшей и худшей частью твоей работы?

Как говорил Конфуций: «Выбери себе работу по душе, и тебе не придется работать ни одного дня в своей жизни».  Обожаю свою работу, не могу выделить какие-то худшие части. Легаси? Сложный заказчик? На самом деле это сложности, которые интересно преодолевать. Ведь сделав что-то «вопреки», «несмотря на» испытываешь еще большую гордость за результат.

Что нравится? В разработке я увлекаюсь проектированием. Обожаю моменты, когда нужно расширить/поменять функционал, а ты уже заранее заложил такую степень гибкости системы, что это делает на «раз два»

Еще обожаю, когда прокачивается моя команда, ребята из сообщества — очень круто осознавать, что в их крутости есть и твоя заслуга.

Давай перейдем к вопросам по Android-разработке.

Какая у вас архитектура в большинстве приложений? Каких паттернов придерживаетесь при разработке?

У нас Clean Architecture: выделяется 3 слоя — domain, data и presentation, для работы с бизнес логикой, данными и UI соответственно. Слои связаны между собой при помощи реактивного подхода и DI. Также для навигации реализован специальный роутинг, пронизывающий два верхних слоя.

Вообще к данной конструкции мы пришли не сразу, потому что на первый взгляд она кажется избыточной. Мы много экспериментировали, то упуская domain слой вообще, то делая расслоение и роутинг вообще по необходимости.

В результате мы остановились на данной конструкции: она обладает необходимой гибкостью и консистентностью и не раз оправдовала себя. Все новые приложения разрабатываются с этой парадигмой, а старые на нее переводятся.

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

У нас следующий основной стек:

• Kotlin,
• RxJava 2,
• Dagger 2/Toothpick,
• Moxy
• Cicerone
• Timber
• Leak Canary
• Сrashlytics
• Joda-Time

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

• Room
• Retrofit 2 + OkHttp 3
• Permission Dispatcher
• Glide /Fresco
• Input Mask
• Fotoapparat

Их собственно и считаем надежными и проверенными. Остальные фреймворки/библиотеки используем по необходимости — на самом тут придерживаемся позиции: «Перед использованием прочитайте все исходники» ну и конечно, «Пересчитайте звездочки на Github-е» ;)

А как осуществляется внедрение новой, потенциально полезной библиотеки? Есть человек-инноватор или группа людей, которые включают библиотеку в проект и изучают ее?

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

Расскажи о тестировании. Как оно происходит? При помощи каких библиотек и подходов?

Мы проектируем систему таким образом, чтобы Android, iOS и Frontend являлись «тонкими клиентами», содержащими минимум бизнес логики, а основную нагрузку брал на себя Backend/Middleware . Таким образом, мы пишем тесты только там, где они действительно нужны и наш абсолютно тестируемый код, не всегда получает значительное покрытие тестами.

В отличии от разработки, у нас пока не сложился единый подход к тестированию и набору библиотек и фреймворков для него - здесь мы находимся на стадии поиска оптимального решения. Mockito, JUnit, Spek — в настоящий момент работаем с таким набором. UI тесты? Пока что в это не верим — высока вероятность получить ложноотрицательный результат и гоняться за багами на пустом месте.

Как ведете документацию? Что используете для этого, пишете ли документацию к методам.

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

Вообще, я считаю, что код должен быть самодокументируемый, исключением могут быть сложные случаи бизнес логики или решения, которые на первый взгляд кажутся не очевидными. Добавление документации типа «Получить заказ» у метода “getOrder()” это не только лишняя работа, но и отличный способ сделать понятный интерфейс класса запутанным.

Как выкладываете релиз? Постепенно или сразу, есть ли фокус-группы.

В зависимости от приложения: при большой аудитории делаем постепенную раскатку, в некоторых случаях, такие как мобильные рабочие места, раскатка нужна сразу же на все аудиторию.

Расскажи немного о команде.

Сколько человек у вас в команде?

В Московском офисе 15 человек, в Питере — 9. Также в группе компаний есть юниты работающие под свои брендом. В Общей сложности Android команда порядка 40 человек.

Как осуществляется взаимодействие внутри команды? Методология работы.

Обычно методология, по которой ведется проект выбирается исходя из потребностей заказчика. Мы стараемся не слепо следовать какому-то процессу, а подстраивать его под свои нужды. Методология должна решать проблемы а не создавать их. Я считаю, что наилучший для команды вариант релизного цикла — 3-х недельные итерации и “Release Train”. Однако это не всегда возможно, например, если в бизнесе заказчика нужны релизы каждые 2 недели или фичи нужно реализовать к какой-то определенной дате.

Как осуществляется взаимодействие между отделами? Например, отделом разработки и дизайна, или между разработчиками и отделом тестирования.

Взаимодействие — это обмен артефактами и их обсуждение. Артефакты, которые предоставляет дизайн подразделение разработчикам — карты экранов и нарезка. Прототипы дизайна выкладываются в систему совместного редактирования и обсуждения Realtime Board, а итоговые макеты в Confluence и Zeplin для хранения документации и предоставления нарезки соответственно.

При работе с аналитиками используется похожая схема, только здесь не нужны никакие инструменты кроме Confluence.

Тестировщикам же уже предоставляем артефакты мы — все сборки поставляются через Fabric.io и Alfa/ Beta Google Play. Сборки собираются билд сервером.

Как осуществляется работа с системой контроля? Делаете ли код ревью?

Мы используем стандартный GitFlow  —  тут ничего не изобретали. Весь код, который попадает в develop ветку проходит обязательное код-ревью. Схема код-ревью зависит от размера команды. Обычно достаточно одного ревьюера; при сложных фичах или изменениях, затрагивающих все приложение, ревьюит вся проектная команда, включая проектного лида.

Как попасть в вам в команду? Какой уровень знаний нужно, чтобы у вас работать?

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

Еще один способ попасть в команду Роботов — пройти стажировку и получить по ее результату оффер.

Спасибо. Уверен, для многих читающих это интервью, такая информация будет полезной. И последний вопрос: а какой разработчик для тебя супер крутой? Понимаю, что тот, который имеет опыт разработки. Но ведь опыт-опыту рознь.

Как охарактеризовать супер крутого разработчика?

Во-первых, должна быть отличная теоретическая база как в Android, так и в программировании в целом. Причем это не просто заученная документация, а глубокое понимание принципов, знание возможных альтернатив и понимание как это ложится на практику.

Во-вторых, должна присутствовать критическая точка зрения и постоянное стремление к совершенству.

Наконец, необходим опыт командной работы и принятия значимых решений.

Обсудить архитектуру Android приложений с Александром и другими ребятами можно в чате Android Architecture. Если у вас есть какие-то сомнения в архитектуре, то смело задавайте их туда. 

Также с вопросами по библиотеке Moxy приходите в чат @moxy_ru.

Подписывайтесь на канал Android Live, где я стараюсь публиковать свои мысли о разработке, статьи и подборки.

С удовольствием отвечу на ваши вопросы по каналу, а также буду рад услышать ваши отзывы.