Мобильное приложение на Flutter: 5 ошибок, которые допускает бизнес

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

За время работы с Flutter мы выпустили в свет более 15 проектов и на собственном опыте убедились, что Flutter подходит для решения большого спектра задач разных отраслей бизнеса.

Мы убедились, что Flutter подходит не только для создания мобильных приложений — с помощью кроссплатформы можно создавать и PWA-приложения (Progressive Web Application), и даже сайты.

А ещё мы увидели, что есть определённый пул типовых ошибок, которые часто допускает компания, решившая создать своё мобильное приложение на Flutter.

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

Буквально каких-то 3 года назад Flutter интересовал только узкий круг разработчиков, а клиенты относились к новой технологии крайне настороженно. Те представители бизнеса, что решались реализовать своё приложение на Flutter, долго и тщательно выбирали подрядчика, потому что опытных разработчиков на рынке были единицы. Делать такой проект своими внутренними ресурсами решались только такие гиганты, как китайский концерн Tencent, который может позволить себе держать практически неограниченный штат разработчиков инхаус и обучать их новой технологии, или Google, который сам является автором Flutter.

Но времена изменились. Google преодолел все проблемы роста своей новой технологии и показал, что готов вкладывать много ресурсов в её дальнейшее развитие. Число проектов, реализованных на Flutter, достигло 400 000, согласно статистике Google. Популярность фреймворка среди разработчиков тоже резко выросла.

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

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

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

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

Передача происходила в 3 этапа:

Для того, чтобы стандартизировать процесс поиска и проведения технических собеседований, мы создали чек-лист вопросов разработчикам на Flutter:

В чём риск для бизнеса? Сама архитектура мобильного приложения на Flutter предоставляет большую свободу в выборе логики. Однако с ростом проекта можно столкнуться с тем, что на старте она было всё же недостаточно проработана. Это увеличит время на отладку и исправление ошибок в приложении.

Казалось бы, это больше про технических специалистов, но от этой ошибки страдает и бизнес. Увеличивается время на отладку, а значит, и time-to-market проекта. Число строк кода больше, а значит, разработчики тратят больше времени на то, что разобраться в нём или найти ошибку, а тестировщики — на его тестирование. А стоимость проекта для бизнеса закономерно растёт.

Какие ошибки бывают?

В чём риск для бизнеса: Такой код трудно тестировать и поддерживать.

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

Как можно избежать ошибок? В этом вам может помочь архитектор или опытная команда аутсорс-разработки на Flutter. Ошибки, связанные с логикой — фундаментальные. Чтобы избежать большинства из них и создавать код, который потом легко поддерживать, мы используем лучшие практики из тех подходов, которые уже описаны, задокументированы и достаточно широко используются.

Например, мы на своих проектах разделяем логику с помощью пакета Elementary, который разработан и поддерживается Flutter-разработчиками Surf. Мы используем Elementary в большинстве наших проектов для создания чистой архитектуры и легко тестируемого кода. Она применяется в e-commerce и финтех проектах — там, где заложена работа с анимацией, выпадающими списками, изменением интерфейса при определённых действиях.

Также на Flutter-проектах мы используем метод чистой архитектуры, в которой выделяем основные слои:

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

В чём риск для бизнеса? Некорректная работа приложения, его «подтормаживание» из-за того, что для решения задачи используется Франкенштейн из виджетов вместо одного подходящего.

В интенсивной работе над проектом разработчики зачастую просто не успевают ознакомиться с готовыми решениями. Очень редко кто находит время открыть каталог виджетов и перебрать каждый: изучить возможности, пробовать в действии, изучить API. Тем не менее, знать готовые решения полезно. Часто, в попытке быстрее решить очевидную задачу, разработчики решают её с помощью «монстра из виджетов». А потом оказывается, что уже существует виджет из коробки, который решает задачу гораздо проще.

Как можно избежать ошибки? Убедитесь, что ваши разработчики следят за новыми возможностями Flutter и регулярно изучают его инструменты. Flutter предлагает множество доступных “из коробки” виджетов, которые могут решить большинство задач.

Какие виджеты есть во Flutter:

В чём риск для бизнеса? Часто разработчики могут откладывать релизную сборку из-за большого количества других задач и ощущения, что можно всё успеть «потом».

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

Как можно избежать ошибки? Контролируйте, чтобы ваши разработчики настраивали релизные сборки заранее. Настроить сборку на Android несложно и может появиться ложная иллюзия, что так же будет и с iOS. Однако на сборку iOS нужно гораздо больше времени. Поэтому первое, что нужно делать при старте проекта — это заранее всё настроить. Так бизнес потеряет меньше на срочных правках.

Небольшая шпаргалка для команды разработки, когда и какой режим сборки стоит использовать:

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

Если приложение написано на одном языке программирования, в случае с Flutter — на Dart, нужно всё равно заложить механизм локализации. Это не займёт много времени на старте, зато сильно облегчит процесс, в случае, если локализация потребуется в дальнейшем. Переписать приложение, в котором локализация не предусмотрена, практически невозможно — нужно будет создавать всё с нуля.

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

Техническая подсказка

Во Flutter есть intl — инструмент интернационализации и локализации. Также это решение включает перевод сообщений, простановку множественного числа и рода, форматирование и синтаксический анализ даты. Если intl пугает своим масштабом, можно использовать плагины для Android Studio и VS Code. Они будут генерировать всё сами, а работать с локализацией станет легче.

Мы часто видим проекты, в которых перечисленные выше ошибки повторялись вновь и вновь. Часто такие проекты становятся разочарованием для всей команды. Разработчики винят Flutter, в том, что он недостаточно развит для использования в крупном и сложном проекте. Менеджеры проекта винят разработчиков в «закапывании» в код, в то время как срок релиза поджимает. Тестировщики в шоке от объёма свалившихся испытаний, а владелец продукта и вовсе не понимает, что происходит внутри проекта.

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

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