Предыстория
Последние годы я фокусируюсь на мобильной разработке с точки зрения собственной экспертизы и бизнеса. За это время собрал несколько команд, попробовал разные сферы, поработал с Xamarin и ушел от него на Flutter, ищу куда развиваться дальше.
Обзор рынка в СНГ сейчас дал какую‑то однобокую картину: курьер может заработать больше, чем предлагают по вакансиям в разработке.
Кажется, что после COVID стало нормальным, когда у специалиста несколько работ.
Может, и работодатели уже смирились с этим? «Задачи закрываются и ладно».
Я начинаю исследование, чтобы понять, можно ли всё это узаконить и отладить процесс со сниженной ролью в заказной разработке.
Начну с темы, на которой я фокусировался последнее время — мобильная разработка на Flutter.
В этой статье
Пошаговая структура разработки:
Аналитика и постановка задачи
Дизайн и ожидания пользователей
Разработка и автоматизация
Тестирование и роль QA
Релиз-менеджмент и ветвление
Подготовка к релизу: чеклист
Что дальше?
Начнем по шагам: постановка задачи, аналитика, дизайн, разработка, тестирование, релиз, следующий цикл
Какое приложение создаем?
Когда хочешь сделать приложение, нужно понимать, что ты хочешь сделать.
Это — роль аналитика. Без неё никуда. Сохраняем её в команде.
Оговорюсь, что иногда её исполняет Project Manager, когда ресурсов мало и нужна сильная коммуникация с заказчиком. Усиливает роль тем, что GPT помогает расписывать требования — знай успевай накидывать и делать факт-чек.
Примечание: факт‑чеку будет посвящена отдельная статья, потому что много копий сломали с моим приятелем системным аналитиком, обсуждая «стоит ли доверять GPT проработку требований и документацию, или проще написать самому, чем проверять за ним».
Как будет выглядеть?
Теперьесть требования — кажется пора писать код. Так как у нас самостоятельные, опытные разработчики, то они дальше сами все сделают. Это может работать: опытный разработчик заложит uikit и вероятно даже структурирует проект. Но чаще: нет общей картинки — нет системности, а согласование новых разделов происходит «на пальцах», а это ведет к новым и новым ошибкам, что замедляет разработку. Есть решение в виде готовых дизайн систем. Например Material Design.
Дальше вопрос: насколько нам подходит шаблонный дизайн (например, Material)?
Как правило, сейчас это не работает. Пользователи искушены. Продукт должен не просто работать, но и выглядеть нормально. Иначе выберут конкурента.
А что такое «нормально»? Здесь тысяча школ и подходов. Дело вкуса.
Никакой AI не угадает, как заказчику «нормально».
Поэтому делаем упор на дизайнеров, но объясняем им правила разработки и генерации компонентов и вёрстки из Figma.
Итого у нас есть:
требования,
дизайн,
кодогенерация традиционными способами и с помощью AI.
Как будем разрабатывать?
Здесь я хочу разобрать инструменты и их эффективность, но главное — отстроить процесс, чтобы AI‑инструменты забрали максимум рутины в разработке.
А принятие решений на уровне ревью и факт‑чека оставались за разработчиком.
Основные опоры:
1) Код, требования, дизайн, документация — всё храним в одном репозитории:
тогда могут работать штуки вроде Cursor
git, git diff, Merge Request — как инструмент акцепта со стороны разработчика
git как связующее звено для разных промтов
2) CI/CD как основа для факт‑чека. Усилена e2e, golden и widget‑тестами
3) Идём от TDD, так как важен факт‑чек
Контроль результата
Итак, у нас появился какой‑то код и регулярные сборки.
И тут мы доходим до проверки того, что же у нас получилось.
Речь про QA.
Ослабление роли разработчика, повышение общей непредсказуемости, а значит — рисков, приведёт к тому, что нагрузка на QA вырастет.
По сути, эта компетенция становится bottleneck и кузницей кадров для подобной структуры.
Базовые подходы:
всеобъемлющий подход к тестированию: требований, дизайнов, приложения
анализ corner‑cases — желательно на уровне требований
составление базы скриптов
автоматизация тестирования
Делаем релиз
Последняя составляющая — релиз‑менеджмент.
Первое — это стратегия работы с ветками: здесь будет взят базовый GitFlow. Главное — он понятен разработке. Можно вести несколько параллельных веток.
Но подход будет усилен шагом в сторону Trunk‑Based за счёт тотального использования feature‑flags:
на уровне сборки
на уровне CI/CD
Причины:
версии могут сильно разойтись → усложнение merge»ей → повышение вовлечения разработчиков
для работы с AI удобнее иметь одну версию продукта
Второй важный момент: приоритизация багов и работа с версионированием и зависимостями.
Что важно для подготовки релиза?
Кратко:
Обновляем версии приложения
Обновляем версии пакетов на последние стабильные
Прогоняем линтер, тесты, устраняем ворнинги
Запрашиваем рекомендации по рефакторингу у AI, делаем поиск ошибок (после merge что‑то могло пойти не так)
Ставим в работу приоритизированные баги по итогам релиза
Ставим в работу фичи
Описываем риски для QA по пунктам 2–6
Делаем сборки и смоуки с QA после пунктов 2–5
Такой процесс я держу сейчас в голове.
Следующий шаг
подбор инструментов, промтов
шаблон приложения (отдельная статья)
обкатка MVP на примере приложения (отдельная статья)
Буду рад вопросам, комментариям, дополнениям.