Dart/Flutter: с чего начать, чтобы не страдать
Привет! На связи Иван и Михаил, Flutter-разработчики из Финама. Когда мы начали писать на Flutter, поняли — граблей тут много, и на некоторые мы уже успели наступить, собрали бинго и готовы рассказать, где они поджидают. Делимся «анти-чеклистом» — вдруг поможет сэкономить время и нервы:
«Книга — лучший подарок», но не в этом случае
Первая ошибка — искать идеальную книгу по Flutter, язык и фреймворк меняются быстрее, чем успевает выходить новое издание. Через пару месяцев некоторые главы могут быть уже неактуальны.
Что делать? Читать документацию, она обновляется. Поначалу может быть трудно вникнуть, опираясь только на нее. На этот случай есть запасной вариант — пройти какой-нибудь годный курс (вроде Udemy). Выбирайте те, где обновления выходят после каждого релиза.
Где брать актуальную информацию
Чтобы не отстать, нужно искать и читать свежие статьи про Flutter и Dart. Из русскоязычных источников нам помогает, конечно, Хабр, а еще рекомендуем ТГ-канал Amiga. Хорошие статьи на английском выходят на Medium. На Youtube-канале Flutter регулярно публикуют интересные видео. А еще мы попробовали лайфхак с нейросетью: она собирает дайджест свежих материалов за неделю. Удивительно, но это правда работает.
Начни со стейт-менеджментов и правильной архитектуры приложения
Самая частая боль новичков — хаос в коде. Мы видели проекты, где бизнес-логика жила прямо в build(). Всё работало… до первого бага.
Как действовать:
Начните с простого setState — это базовый способ управления состоянием. Затем попробуйте пакеты Bloc, Riverpod — почувствуете разницу в читаемости и структуре.
Изучите основы чистой архитектуры: это позволит вам быстрее понимать чужой код и лучше разбираться в своем.
Хотите потренироваться? Попросите AI сгенерировать пример проекта с Bloc — и разберите его построчно. Или обратитесь к статьям.
Не бойся проблем при сборке
При сборке проекта ты скорее всего столкнешься с ошибками компиляции и в 90% случаев это будут ошибки, связанные с Xcode и Gradle. Не нужно паниковать, Flutter достаточно умен и в большинстве случаев предложит тебе решение. Если не было предложено решение или оно не сработало — не беда, первая ссылка в гугле вероятнее всего решит твою проблему. И не забывайте про старый дедовский способ перезагрузки:
flutter clean
flutter pub get
В топку тяжелые среды, работай по четвергам в Visual Studio Code
Среда разработки — твой основной инструмент, ты будешь работать в ней 99% своего времени, а значит она должна быть удобной и комфортной для тебя. Для Flutter есть две основные IDE: Android Studio и Visual Studio Code. Android Studio — мощная, с готовыми тулзами и анализаторами, но тяжеловесная. VS Code — лёгкий, быстрый и гибкий.
В Финаме мы работаем в VS Code — там проще интегрировать CLI-инструменты, автогенерацию кода и кастомные скрипты. Но выбор — это вопрос привычки: рекомендую попробовать обе. Главное, чтобы IDE не тормозила, когда запускаешь hot reload 20 раз в час. Я знаю людей, которые переходили с Android Studio на Visual Studio Code, но не знаю обратных примеров.
Логике в UI не место
Выгружать логику работы приложения (например, сетевые запросы, обработку данных) в методе build() — грубая ошибка. Это ведет к багам, фризам, затрудняет тестирование, нарушает принципы разделения обязанностей.
Используйте стейт-менеджеры. Логика должна быть отделена от UI — это облегчает поддержку, переиспользование и покрытие тестами.
Делите UI на независимые виджеты
Если экран превращается в тысячу строкового монолита — значит пора рефакторить. Разбивайте интерфейс на маленькие, самодостаточные виджеты (например: заголовок, список, кнопки). Это упрощает чтение, тестирование и повторное использование компонентов. И старайтесь ограничивать один экран не больше 150-200 строками кода.
Async — не просто await
Асинхронное программирование в Dart требует внимания:
Оборачивайте важные вызовы в try/catch.
Используйте async/await для читаемого кода; а если используете .then(), не забывайте обработать
