Обширный контрольный список для запуска нового проекта Flutter

Создание нового проекта Flutter - это благословение: свежая кодовая база, отсутствие устаревшего кода (пока), безопасность с нулевым значением, самые последние версии ваших любимых пакетов и так далее. Но в то же время вы должны принять важные решения в начале проекта, которые заложат фундамент для будущего, такие как инструменты, пакеты, файловая структура, решение для управления состоянием, план тестирования. В противном случае проект со временем превратился бы в очередную тарелку спагетти и фрикаделек. Чтобы этого избежать, я подготовил список, на мой взгляд, наиболее важных элементов проекта, которые следует решить на ранней стадии. Надеюсь, это поможет вам, поэтому - желаю приятного чтения!

1. Статический анализ кода

ЛИНТЕР - это инструмент статического анализа, который выявляет и помечает ошибки программирования, предупреждения и недостатки стиля в вашем коде, чтобы вы могли их исправить. В контексте Flutter это одна из самых простых вещей для реализации и одна из самых полезных для поддержания чистоты вашего кода.

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

Какой бы пакет вы ни выбрали, вы всегда можете добавить или удалить любое конкретное правило статического анализа в файле analysis_options.yaml.

2. Локализация (l10n)

Что такое локализация (короче l10n)?

Локализация - это адаптация продукта или услуги к потребностям определенного языка, культуры или желаемого внешнего вида населения. - TechTarget

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

Документация Flutter тонко объясняет процесс интернационализации вашего приложения. Если способ по умолчанию кажется слишком сложным и / или вам нужны полезные расширения и вспомогательные методы, существуют популярные сторонние пакеты, такие как easy_localization, которые могут помочь вам в процессе локализации.

3. Среда (с некоторыми ароматизаторами)

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

  • Среда разработки (локальная) - используется для вас: экспериментируйте с кодом, изменяйте данные прямо в базе данных, используйте ярлыки и жестко закодируйте токен аутентификации или предоставьте ложные данные. Получайте удовольствие и предоставляйте эти функции!
  • Промежуточная среда (тестирование или промежуточная) - помогает вам проверить изменения в коде, протестировать функции с «реальными» данными (обычно это снимок производственных данных. используется в таких средах) и проверьте приложение, прежде чем выпускать его в производство. Если в вашей команде есть инженеры по обеспечению качества, это место, где они могут проявить себя.
  • Производственная среда - та, которая используется реальными пользователями, где повреждение данных недопустимо (всегда делайте резервные копии, пожалуйста).

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

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

4. Непрерывная интеграция и непрерывная доставка (CI / CD)

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

Однако существует множество решений NoOps, совместимых с Flutter, поэтому вы можете легко автоматизировать процесс разработки:

  • Appcircle;
  • Codemagic;
  • Bitrise;
  • VS App Center (еще не имеет интеграции с Flutter, но есть ресурсы, которые могут помочь вам все настроить).

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

5. Бэкэнд-код

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

В упрощенной версии есть два варианта серверной части вашего приложения:

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

Если второй вариант кажется вам привлекательным, есть несколько отличных облачных платформ, поддерживающих Flutter:

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

6. Ведение журнала, данные о сбоях и аналитика.

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

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

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

7. Брендирование приложений.

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

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

8. Структура проекта и государственное управление.

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

Несколько вариантов структуры файлов для следующего проекта Flutter:

  • Чистая архитектура - четкое разделение проблем, существует давно. Честно говоря, я не фанат этого. Мне кажется, что в этой концепции слишком много абстракций, которые могут замедлить процесс разработки.
  • Многоуровневая архитектура - основана на идее разделения данных, бизнес-логики и логики представления на отдельные уровни. Такая файловая структура отлично работает для малых и средних проектов, но я чувствую, что эти слои становятся все более и более подавляющими по мере роста проекта.
  • Модульная архитектура (я описал эту концепцию здесь) - разделение кода на модули по функциям, в которых взаимодействуют разные модули. Это мой любимый вариант - он отлично работает с решением управления состоянием BLoC (TEAM BLOC, ДА!), Хорошо масштабируется для больших проектов. Однако это создает некоторые проблемы, например, где разместить общую логику, как разные модули должны взаимодействовать и так далее.

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

9. Генерация кода

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

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

Для быстрого старта проекта Flutter я бы порекомендовал проверить Very Good CLI. Это сэкономит вам несколько часов настройки (к сожалению, я выучил это на собственном горьком опыте).

Кроме того, в прошлом месяце я говорил о генерации кода - это может стать отправной точкой в ​​вашем путешествии по генерации кода Flutter, так что проверьте это!

10. Стратегия тестирования

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

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

  • Бизнес-логика (службы, репозитории, BLoC) должна быть покрыта на 85–100% в модульных / интеграционных тестах - это самая важная часть любого приложения, поэтому я вижу большую ценность в тестах;
  • Тесты виджетов должны охватывать все повторно используемые компоненты пользовательского интерфейса. Когда отдельные компоненты протестированы должным образом, вы можете начать тестирование отдельных экранов, но менее подробно.
  • Сквозные тесты, охватывающие основные потоки приложений и взаимодействия с пользовательским интерфейсом. Никакой глубокой магии - просто прохождение некоторых важных рабочих процессов. Чем больше экранов они включают, тем лучше.
  • Когда весь пользовательский интерфейс готов и реализован - золотые тесты, чтобы убедиться, что изменения не повлияют на пользовательский интерфейс в дальнейшем.

Честно говоря, я все еще ищу эту золотую середину в тестировании, но вы становитесь лучше в этом проекте за проектом, поверьте мне.

11. Файл README.

Вы меня правильно поняли - документация. README файл - самый важный документ проекта, особенно при работе в команде.

Вы только что представили новое решение, требующее генерации кода? Вы только что добавили новый полезный сценарий bash для автоматизации процесса? Вы реализовали глобальный регистратор, который ДОЛЖЕН использоваться повсюду в проекте? Мы не можем читать ваши мысли - укажите это в файле README!

Не бывает слишком много документации (по крайней мере, я не был в такой ситуации), только отсутствие информации о проекте и коде. Все команды для генерации, тестирования и запуска кода, различные решения по структуре файлов, диаграммы, внешние инструменты и службы, информация о различных средах (БЕЗ СЕКРЕТНЫХ КЛЮЧЕЙ) должны быть помещены сюда и храниться в одном месте. Это скучная работа, но очень полезная!

Вот и все! Спасибо, что уделили время чтению этой статьи.

Я что-то пропустил? Упомяните об этом в комментариях! Каков ваш контрольный список при создании нового приложения Flutter?

👏 Нажмите кнопку хлопка ниже, чтобы выразить свою поддержку и побудить меня писать лучше!
💬 Оставьте ответ на эту статью, поделившись своими мыслями, комментариями или запросами на будущие статьи.
📢 Поделитесь этой статьей со своими друзья, коллеги в социальных сетях.
➕ Подписывайтесь на меня на Medium и просматривайте другие статьи.
🍿 Подпишитесь на мой канал YouTube - скоро будет больше контента!
✉️ Не стесняйтесь писать в DM меня в Twitter и поделись своим мнением о… чем угодно!

Подпишитесь на сообщество Flutter в Твиттере, чтобы увидеть больше отличных статей: https://twitter.com/FlutterComm