Какие плюсы и минусы использования сторонних зависимостей (пакетов) в Flutter-проекте?

Ответ

Плюсы:

  • Ускорение разработки: Не нужно изобретать велосипед для стандартных задач (навигация, HTTP-клиент, локальное хранилище). Например, использование dio вместо ручного написания HttpClient.
  • Надежность и тестированность: Популярные пакеты (provider, bloc, shared_preferences) проходят проверку сообществом, что снижает количество собственных багов.
  • Доступ к сложной функциональности: Позволяют легко добавить карты, аналитику, push-уведомления или сложные анимации, которые сложно реализовать с нуля.
  • Следование best practices: Хорошие пакеты часто демонстрируют современные подходы к архитектуре и дизайну кода.

Минусы:

  • Риск заброшенности пакета: Автор может перестать поддерживать пакет, что приведет к проблемам с совместимостью при обновлении Flutter SDK.
  • Конфликты версий и транзитивные зависимости: Несколько пакетов могут зависеть от разных версий одной библиотеки, что требует ручного разрешения в pubspec.yaml.
  • Раздувание размера приложения (app bundle): Каждый пакет добавляет свой код и нативные зависимости, увеличивая итоговый размер.
  • Сложность отладки: При возникновении проблемы внутри кода пакета, его отладка может быть затруднена.
  • Избыточность: Пакет может тянуть за собой много функционала, из которого используется лишь малая часть.

В моих проектах я придерживаюсь баланса: для базовых вещей (управление состоянием, сетевые запросы) беру проверенные пакеты с высоким рейтингом на pub.dev, а для специфичной бизнес-логики пишу собственные решения. Перед добавлением пакета я всегда смотрю на его активность, количество открытых issues и поддерживаемость.

Ответ 18+ 🔞

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

Плюсы, они вроде как очевидные:

  • Разработка быстрее, чем угорелая. Ну серьёзно, зачем мне вручную этот HttpClient ебать-колотить, выписывать хедеры, парсить ошибки, когда есть тот же dio? Берёшь, подключаешь — и уже через полчаса работающий запрос с нормальной обработкой всего и вся. Это как не печь хлеб, а купить в магазине. Экономия времени — овердохуища.
  • Штуки проверенные, не с потолка. Популярные библиотеки вроде provider или bloc их уже тысячи людей облизали, протестировали в бою. Шанс, что там какая-то детская ошибка, — почти ноль. Доверия к такому коду больше, чем к своему, написанному в три ночи.
  • Доступ к сложной магии. Хочешь карты? Пуш-уведомления? Сложную анимацию, от которой глаза на лоб лезут? Да без проблем, вот тебе пакет. Реализовать это самому — это ж надо мозги вывихнуть и месяц жизни потратить. А так — pub add, и через пару дней фича уже в продакшене.
  • Учат, как надо. Глядя на код хороших, популярных пакетов, сам начинаешь понимать, как правильно архитектуру строить, код организовывать. Это как бесплатный мастер-класс от опытного разработчика.

Но минусы, блядь, такие, что иногда хочется всё удалить и на чистом SDK писать:

  • Главная страшилка — пакет накрылся медным тазом. Представь: полгода назад взял модную библиотеку для графиков, всё летало. А сейчас обновляешь Flutter, а автор пакета — хуй с горы, пропал, и его творение с новой версией не дружит. И всё, сидишь и думаешь: или откатывайся на старый Flutter, или срочно ищи альтернативу, или сам допиливай этот заброшенный код. Терпения ноль, ебать.
  • Ад зависимостей, ёпта. Это когда один пакет хочет версию json_annotation 4.8.1, а другой — 4.7.0, и они начинают друг другу глотки рвать в твоём pubspec.yaml. И ты сидишь, этот конфликт разрешаешь, как дипломат на переговорах. Иногда проще отказаться от одного из них, чем в это вникать.
  • Размер приложения растёт как на дрожжах. Каждый пакет — это лишний код, а иногда и нативные библиотеки. Ты добавил пять небольших пакетиков, а размер app bundle вырос на 15 мегабайт. Пользователь скачивает, а там половина — это хлам, который ты даже не используешь. Удивление пиздец.
  • Отладка превращается в квест. Если баг в твоём коде — полбеды. А если он где-то там, в глубине чужой библиотеки? Ты даже исходники смотреть не всегда готов, не то что исправлять. Чувствуешь себя беспомощным.
  • Избыточность. Часто берёшь здоровенный пакет ради одной мелкой функции. А он тебе за собой тянет целый вагон неиспользуемого кода. Как будто купил целый завод, чтобы гайку одну получить.

Как я с этим живу? Баланс, чувак, только баланс. Для фундаментальных вещей — управление состоянием, работа с сетью, локальное хранилище — беру только топовые, проверенные временем пакеты с кучей звёзд на pub.dev. Смотрю, когда было последнее обновление, сколько открытых issues, читаю комменты. А вот всю свою, уникальную бизнес-логику пишу сам. Не доверяю такое сторонним решениям. И перед тем как добавить любой новый пакет, задаю себе вопрос: «А оно мне правда надо, или я просто ленюсь пару часов свою утилиту написать?». Часто ответ оказывается неожиданным.