Как стать автором
Обновить
105.92
Рейтинг
Россельхозбанк
Меняем банк и сельское хозяйство

Быстрее нативной разработки: опыт внедрения Flutter в крупной компании

РоссельхозбанкFlutter

Хотя сообщество мобильных разработчиков давно нахваливает Flutter, большие компании не спешат переходить на эту технологию. Так получилось, что здесь мы стали одними из первых: когда понадобилось быстро выпустить новое приложение, мы взвесили все «за» и «против», опробовали гугловский фреймворк и остались довольны. Чем хорош Flutter, как выстраивается процесс разработки, где искать специалистов, какие нюансы и подводные камни нужно учитывать – обо всём этом расскажем под катом. Поехали.

Задачи: почему мы вообще в это ввязались

О Flutter мы были наслышаны. Нам давно хотелось опробовать эту перспективную технологию, и в начале этого года новый проект представил такой случай. Задача состояла в следующем: за 3–4 месяца разработать кроссплатформенное приложение, с помощью которого фермеры могли бы продавать свою продукцию конечным потребителям. Эта новая торговая площадка должна предоставлять участникам удобные инструменты:

  • фермерам – для создания своих цифровых витрин с текстовыми описаниями и изображениями товаров и агротуров, с возможностью настраивать правила торговли и добавлять адреса

  • покупателям – для формирования корзины из фермерских продуктов и оформления заказов

Поиск решения: почему выбрали Flutter

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

По большому счёту, выбирали между нативом и Flutter. React Native и Xamarin отбросили почти сразу, с ними уже имелся опыт – не очень удачный. Также рассматривали PWA, но этот вариант тоже пришлось забраковать: на момент выбора там было не всё хорошо с поддержкой нативных функций системы, особенно в iOS. К тому же для хорошей поддержки требовались свежие версии OS, что тоже могло стать проблемой. В общем, изучив вопрос поглубже, решили не собирать грабли.

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

  • достаточно быстрый, за счет компиляции, сравним с нативом

  • виджетный (компонентный) подход, сродни React

  • кроссплатформенный – меньше кода, потенциально упрощает тестирование

  • богатый инструментарий разработчика – IDE и прочее

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

  • продукт, который развивает и продвигает Google и большое Open-source community

  • крупные компании – Google, Groupon, Alibaba – разрабатывают на нём свои приложения

Были и минусы:

  • мало разработчиков – всего 121 резюме, 11 лидов/сеньоров в Москве

  • дорогие лиды/сеньоры

  • относительно мало технической информации – stackoverflow и т.п.

  • пока мало готовых (сложных) компонентов – стандартные/системные тут не используются

  • язык – новичкам придётся учить Dart (но легко переходить, если есть опыт разработки на Java или JavaScript)

  • сложно найти подрядчиков с опытом

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

Пришлось фантазировать: формирование команды

После выбора решения одним из главных вызовов стало формирование команды под новый проект. О поиске Flutter-разработчиков можно написать отдельную статью. На момент старта проекта — весной 2020 года – подходящих специалистов на рынке было, мягко выражаясь, не густо. HH по запросу «Flutter» выдавал несколько десятков резюме, в которых значился некоммерческий опыт: «Мне было интересно, и я начал разрабатывать своё приложение» или «Уговорил попробовать сделать какой-то простенький внутренний проект в компании».

И всё же через HH мы нашли нашего первого разработчика, Михаила. Ему так понравился Flutter, что он по собственной инициативе сделал на этом фреймворке приложение для своей компании – но развития оно, к сожалению, не получило. Михаил хотел работать с Flutter дальше, поэтому он вышел на рынок, где мы и нашли друг друга. Вместе с ним формировать команду мобильной разработки стало немного проще: появилась своя компетенция.

Основная масса специалистов по Flutter — это младшие разработчики, которые только начинают свой путь, а также старшие или ведущие, у которых есть время изучать современные технологии и пробовать их в виде proof of concept. Проще всего адаптироваться к Flutter тем, кто имеет опыт Android-разработки. На втором месте web-разработчики: react, vue.js – здесь близкий по духу компонентный подход.

И всё же людей на рынке было крайне мало, а в активном поиске – ещё меньше. С начинающими разработчиками мы решали и решаем вопрос в т.ч. за счёт нашей стажёрской программы для студентов старших курсов вузов, где под руководством опытных наставников ребята становятся полноценными джунами. Так было с Евгением, который пришёл к нам на стажировку по мобильной разработке. Обучался под руководством Михаила почти со старта проекта и достаточно быстро дошёл до продуктовых задач.

Однако с синьорами и мидлами дело было совсем плохо, обычные каналы поиска не работали. Пришлось фантазировать: искали людей в тематических telegram-каналах и через Хабр, среди авторов статей по Flutter. С подходящими кандидатами списывались, общались, давали тестовые задания. Это вынудило нас расширить географию на всю Россию, что стало новым опытом: до этого мы рассматривали только кандидатов из городов, в которых есть наши офисы – но с Flutter это не работало.

На сегодняшний день география команды довольно обширна: кроме москвичей, у нас работают жители Петрозаводска, Елабуги, Барнаула. Есть кандидаты технических и физико-математических наук. Таким образом, команда формировалась постепенно, параллельно с активной разработкой приложения. Сейчас у нас уже 7 разработчиков, появляются новые проекты на Flutter – мы растём.

Изначально работу выстраивали по принципу feature-driven development (FDD, разработка, управляемая функциональностью). Но впоследствии решили перейти на унифицированный процесс разработки на основе OpenUP: такой способ лучше подходит для управления разработкой всего продукта и координации нескольких команд – архитекторов, аналитиков, разработчиков, тестировщиков. Внутри команд разработки используем Scrum.

Особенности разработки на Flutter

Когда говорят о кроссплатформенной мобильной разработке, часто сравнивают React Native и Flutter. Однако нужно понимать, что React Native – это не история про один код на все платформы. Недаром официальный слоган проекта – Learn once, write anywhere. Дело в том, что в React Native пишут код на JavaScript, который использует нативные для каждой платформы компоненты – и они довольно сильно отличаются. Да, есть общие компоненты, вроде Text и View: под обе платформы, хотя и с нюансами. Но много и таких, что работают только на одной ОС. Поэтому в React Native нередко можно встретить выражения:

if (Platform.OS == 'ios') ...`

При использовании Flutter разработка ведётся на языке Dart, который компилируется в нативный для платформы код. При этом вместо нативных компонентов используется собственная библиотека виджетов, которые выглядят как нативные – Material и Cupertino для Android и iOS соответственно. Вы можете использовать виджеты из обеих библиотек в одном приложении, кроме того, их очень легко кастомизировать.

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

Бывает и так, что есть уникальная для платформы функциональность. Подстановка СМС-кодов верификации на iOS работает по умолчанию, от программиста не требуется никаких действий. А на Android нужно использовать системные методы, чтобы получить этот код программно и подставить в нужное поле. Хотя даже для этой задачи уже существуют Flutter-библиотеки, например, sms_user_consent. Весь платформенный код в ней уже создан, остаётся только добавить свой listener для получения сообщений.

if (Platform.isAndroid) {
  listenForCode();
}
void listenForCode() {
  smsUserConsent = SmsUserConsent(
      phoneNumberListener: () {},
      // Действия при получении смс-сообщения
      smsListener: () {
        Log('code is updated to ${smsUserConsent.receivedSms}');
        final sms = smsUserConsent.receivedSms;
        _smsCodeController.text = sms.substring(sms.lastIndexOf(' ') + 1);
      });
  smsUserConsent.requestSms();
}

Одна из не очень удобных особенностей Flutter – достаточно динамичный релизный цикл. Как и во всех подобных активно развивающихся фреймворках, почти каждое крупное обновление приводит к необходимости внесения изменений в уже написанный код. Например, при переходе с версии 1.20 на 1.22 пришлось потратить несколько часов из-за конфликтов имён классов проекта и встроенных классов Flutter. Тем не менее такие серьезные изменения – скорее редкость, они происходят не чаще трёх раз в год.

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

Разработка на Flutter значительно быстрее, нежели нативная. Если говорить о кодовой базе, то нативный мобильный код по объёму для каждой платформы по отдельности был бы примерно аналогичен Dart-коду, но за счет того, что платформ две, получаем существенное увеличение трудозатрат.

Результаты и выводы: стоит ли разрабатывать на Flutter

Новый фреймворк не подвёл: после полугода разработки MVP доступно в магазинах приложений для Android и iOS. Проект по-прежнему развивается, и в этом очень помогает фидбэк пользователей: мы активно взаимодействуем с фермерами, которые делятся своими впечатлениями от использования платформы. В ближайшем будущем хотим подключить к нашему маркетплейсу сторонние сервисы доставки, внедрить онлайн-платежи, организовать процесс совместных покупок. Для реализации этого нам понадобятся не только мидлы и сеньоры, специализирующиеся на Flutter, но и PHP-разработчики (Senior и Team Lead с опытом Magento 2), а также опытные специалисты по Vue.js. Если видите себя членом нашей новой команды – обязательно пишите!

Нам очень понравилось работать с Flutter. Тем не менее это решение пока нельзя считать универсальным: для нашего проекта оно подошло на 100%, но при разработке какой-нибудь игры или продукта, использующего более сложные и передовые технологии – VR, AR, ML и т.п., – всё могло бы сложиться не так гладко. Впрочем, со временем эта функциональность наверняка подтянется.

Единственный реальный риск — корпоративные войны между Apple и Google. Если политика Apple в отношении приложений на Flutter изменится, это может негативно сказаться на его перспективах. Речь не только о процессе размещения в магазине приложений, но об инструментальных средствах, таких как совместимость SDK.

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

Теги:flutterновые технологиирсхбмобильное приложениеdartроссельхозбанккоманда
Хабы: Россельхозбанк Flutter
Всего голосов 15: ↑14 и ↓1 +13
Просмотры7K

Похожие публикации

Лучшие публикации за сутки

Информация

Дата основания
Местоположение
Россия
Сайт
www.rshb.ru
Численность
свыше 10 000 человек
Дата регистрации
Представитель
ashershov

Блог на Хабре