Всем привет! Меня зовут Милена, я бэкенд‑инженер на Java в Банки.ру. Полтора года назад я вызвалась написать мобильное приложение для команды, в которой не было ни одного мобильного разработчика. За три месяца мы его выпустили, оно работало на обеих платформах, и я закрыла для себя вопрос, ради которого во все это ввязалась «понравится ли мне мобильная разработка» — ответ оказался «нет».

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

Кто вообще будет писать мобильное MVP

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

Нанимать под это отдельную мобильную команду мы не стали. Дорого и долго, особенно для продукта, который сам еще только проверял себя. Выбирали между React Native и Flutter. У нас был фронтенд‑инженер на React, так что React Native выглядел логично, но ему все равно пришлось бы переучиваться. А на Flutter у меня был небольшой опыт: несколько лет назад я написала на нем дипломный проект. Плюс на тот момент он был на слуху. Я предложила сделать приложение сама. Так и решили.

Причин было две. Первая рабочая: команде нужен был человек, и я могла им стать. Вторая моя личная, и именно она держала меня весь проект. Мне давно хотелось понять, а понравится ли мне мобильная разработка настолько, чтобы заниматься ею всерьез. Диплом не в счет: там никто не проверял качество, и настоящих пользователей у него не было. Хотелось попробовать по‑взрослому и получить опыт, который потом пригодится, даже если я захочу выпустить в стор что‑то свое.

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

При этом энтузиазма было больше, чем страха. Мне все равно хотелось попробовать.

Архитектура далась легко

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

Архитектурная часть, как ни странно, далась легко. Бэкендеру не надо объяснять, зачем нужны репозитории, DTO или внедрение зависимостей. Ты примерно понимаешь, что должно получиться, и остается выяснить, как это записать на незнакомом языке. Для управления состоянием мы взяли Bloc. Порог входа у него выше, чем у того, с чем я работала в дипломе, зато он не дает смешивать интерфейс с логикой, и потом это здорово выручило, когда экранов стало много.

Настоящие сложности начались там, где бэкенд закончился.

Дерево, в котором теряется глаз

Самым непривычным оказалась не архитектура, а то, как вообще описывается интерфейс. Я пишу на Java и люблю строгие языки. Открываешь файл, и там понятная структура: классы, методы, слои. А во Flutter ты открываешь файл и видишь виджет внутри виджета, внутри Column, внутри Expanded, внутри Padding. Первое время я буквально теряла в этом дереве глаз. Причем мало разобраться в чужом коде, надо еще писать так, чтобы потом в этом ориентировался кто‑то другой.

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

Если к структуре проекта привыкаешь за неделю, то управление состоянием заняло куда больше времени.

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

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


Что я заметила: когда говорят про Flutter, складывается впечатление, что один код автоматически означает одинаковое поведение везде.

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

«Календарь», на котором я думала все бросить

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

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

Дальше начался замкнутый круг. Правишь одну фичу, ломается другая. Чинишь ее, отваливается первая. Я говорю: все, починила. А наш QA приходит с ответом: а я вот сюда ткнул. И оказывалось, что если зайти на экран, выйти и зайти снова, то все разваливается заново. На бэкенде такого просто не бывает, там сценарий обычно линейный. Мы гоняли этот календарь по нескольким итерациям, и конца этому не было видно. Вот тогда у меня и появилась мысль: куда я вообще залезла.

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

Была еще авторизация через Telegram‑бота, которую мы переносили с веба. В браузере вкладка просто висит, тогда как в мобильном приложении пользователь сворачивает приложение и переходит в другое. За это время sse соединение обрывалось, поэтому пришлось изменить сценарий уже существующего на вебе процесса,а также адаптировать к нему нашего телеграмм бота.

Моим наставником стал ИИ

Когда в команде есть опытный Flutter‑разработчик, можно подойти и спросить: а почему здесь принято делать именно так? У меня такого человека не было. Был купленный курс по Flutter, но ответы на половину вопросов в нем не находились. И моим наставником стал ИИ.

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

Скажу честно: работало это далеко не всегда. Если считать по ощущениям, полезным был примерно каждый второй ответ, может, чуть чаще. Процентов 60/40. В остальных случаях ИИ писал код, который сам создавал баги, и потом я сидела и вычищала его руками.

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

И еще одно ограничение, о котором стоит сказать. Я бы не стала называть ИИ — сеньором. Сеньор знает контекст: как принято в нашей команде, что мы уже используем, куда мы идем. ИИ этого не знает. Он не приходил ко мне сам со словами «слушай, а вот здесь лучше взять вот это». Инициативу приходилось проявлять мне: я узнавала о какой‑то практике со стороны, приносила ее и спрашивала, как правильно внедрить.

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

Главный вывод для меня такой: ИИ не заменяет опытного разработчика рядом. Но если такого человека нет, он сильно сокращает время на разбор теории.

Отдельная деталь, которая сейчас вспоминается со смехом

CI у нас на этом проекте настроен не был, и сборки мы передавали друг другу через Telegram. Работало нормально ровно до момента, пока мессенджер не начали блокировать. Загрузка одного файла стала занимать столько времени, что проще было пойти заварить чай. Никакого решения мы не придумали, просто ждали.

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

Так понравилась ли мне мобильная разработка

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

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

Нет. Flutter не зашел мне настолько, чтобы хотеть заниматься им всерьез.

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

Поняла я это, кстати, не в момент релиза, а раньше, на этапе починки багов. Когда в очередной раз оказалось, что на Android все в порядке, а на iOS отвалилось, и ты сидишь и не понимаешь почему.

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

Что я все‑таки унесла

Опыт при этом никуда не делся, и он оказался полезнее, чем я ожидала.

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

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

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

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

Спасибо, что дочитали. Буду рада пообщаться в комментариях.