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

Это не то же самое, что построить приложение, и доказательства здесь нужны другие. Пообещать пересборку может кто угодно; спасение судят по тому, перестала ли сбоить та конкретная вещь, которая сбоила, — измеримо и не сломав то, что ещё работает. Поэтому каждое спасение у нас начинается с аудита и письменного плана — и поэтому, когда план говорит «две недели исправлений», а не «переписывание», мы так и говорим.

С чем к нам приходят

  • Производительность — подтормаживания на скролле, рывки анимаций, медленный старт, списки, задыхающиеся на реальных объёмах данных
  • Стабильность — растущий уровень крашей, обрывы сессий, утечки памяти, всплывающие только после минут реального использования
  • Брошенные проекты — агентство исчезло, в репозитории неразбериха, и никто не уверен, где лежат ключи подписи
  • Кодовые базы, написанные ИИ — сгенерированный прототип нашёл реальных пользователей и теперь должен их пережить; входная точка для таких случаев — аудит AI-кода
  • Застрявшие роадмапы — архитектура, в которой каждая фича выходит медленнее предыдущей: симптом столь же реальный, как краш

Спасения, на которых стоит эта страница

Живой телемедицинский продукт, стабилизированный в продакшене

YouMi — сервис онлайн-консультаций с психологом, чьё Flutter-приложение жило в обоих сторах и не справлялось ровно с тем, ради чего существовало: сессии обрывались, сообщения в чате не доходили, а утечки памяти в навигационном стеке были такими, что приложение падало при переходах между экранами. За две недели мы перестроили -слой с полноценным жизненным циклом соединения — автоматическое переподключение, очередь сообщений при смене сети, — добавили сквозные статусы доставки и переписали навигационную архитектуру на современных API роутинга Flutter. Приложение при этом ни разу не покинуло сторы. В телемедицине соединение и есть продукт — поэтому именно этот проект открывает страницу: спасение измеряется тем, ради чего продукт существует.

Производительность, проверенная на пределе разумного

Чтобы чинить медленный рендеринг, нужно уметь строить быстрый. Arcana держит чат из тысяч стриминговых markdown-сообщений при 60 fps; ExtraETF держит частоту кадров под живым потоком рыночных данных. Эти потолки важны для спасательной работы, потому что калибруют диагноз: профилируя ваше приложение, мы отличаем «Flutter этого не может» — что редко бывает правдой — от «этот шторм перестроек можно убрать правильным скоупингом», что обычно и оказывается настоящим выводом.

Как проходит спасение

1. Аудит

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

2. Стабилизация

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

3. Закрепление

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

4. Передача

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

Дисциплины, на которые опирается спасение

Работа с частотой кадров

Проблемы производительности сначала профилируются, потом чинятся — на среднем железе, под реальными данными, с открытым таймлайном. Обычные находки: незаскоупленные перестройки, каскадом идущие по дереву виджетов; списки, перестраивающие строки, которые должны переиспользоваться; работа во время build, которой там не место. Производительность — свойство инженерии, а не фреймворка: та же дисциплина, что держит стриминговый чат на 60 fps, убирает рывки с продуктового экрана.

Рефакторинг управления состоянием

Многие сбоящие приложения сбоят структурно: состояние размазано по экранам, зависимости неявные, одно изменение отзывается пятью регрессиями. Мы рефакторим поэтапно — экран за экраном, под защитой тестов, пока приложение продолжает релизиться, — вместо того чтобы объявлять переписывание. Цель — архитектура, в которой следующая фича дешевле предыдущей: именно так «застрявший роадмап» из списка симптомов начинает двигаться в обратную сторону.

Надёжность реального времени

Оборванные сессии и недоставленные сообщения — это баги жизненного цикла: соединения без политики переподключения, сообщения без статусов доставки, сокеты, молча умирающие при смене сети. Лекарство — полноценный жизненный цикл соединения, построенный один раз, с ясным владельцем, — дисциплина, которую демонстрирует проект YouMi, и причина, по которой он занял две недели, а не квартал.

Память и навигация

Утечки, роняющие приложение после десяти минут использования, прячутся в удерживаемых экранах, слушателях, переживающих свои виджеты, и навигационных стеках, которые не отпускают то, что в них запушили. Мы переписываем навигацию на современных API роутинга Flutter там, где этого требует архитектура — у YouMi требовала, — и проверяем исправление профилями памяти, а не оптимизмом.

Передачи от исчезнувших агентств

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

Когда это действительно переписывание

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

Сколько стоит спасение

Аудит — проект с фиксированным объёмом: 450 тыс. ₽ – 1,4 млн ₽, тот же тариф полного аудита, что опубликован на странице аудита AI-кода, — машинерия одна и та же независимо от того, писало код агентство, внутренняя команда или модель. Работа по стабилизации затем скоупится по последовательному плану аудита, симптом за симптомом, — вы утверждаете работу порциями, а не подписываетесь вслепую. Если хотите, чтобы рабочие руки остались и после, действует опубликованная ставка расширения команды: 900 тыс. ₽ – 1,3 млн ₽ за senior-инженера в месяц.

Мы не называем цену стабилизации до аудита: цифра, произнесённая без взгляда на кодовую базу, — догадка в деловом костюме, а большинство команд, доходящих до спасения, ровно на таких сметах уже однажды обжигались.

Частые вопросы

Что чаще всего спрашивают команды, чьё Flutter-приложение сбоит в продакшене.

Да — часть нашей лучше всего задокументированной работы началась ровно так, включая живой телемедицинский продукт, который мы стабилизировали, не выводя из продакшена. Перехват начинается с аудита кодовой базы и инвентаризации того, что вы на самом деле контролируете: доступ к репозиторию, ключи подписи, аккаунты в сторах, документация бэкенда. Вы получаете письменный отчёт с находками и последовательный план до любого разговора о пересборке — потому что иногда ответ — «две недели исправлений», а не переписывание, и когда это так, мы так и говорим.
Профилируя до того, как что-либо менять, — на среднем железе, под реальными объёмами данных, с открытым таймлайном производительности. Обычные причины — незаскоупленные перестройки виджетов, идущие каскадом по дереву, списки, перестраивающие строки вместо переиспользования, и тяжёлая работа во время build. Сам Flutter редко оказывается потолком: фреймворк держит 60 кадров в секунду на стриминговых, насыщенных анимацией экранах, когда рендеринг дисциплинирован, — так что лекарство почти всегда в правильном скоупинге работы, а не в борьбе с фреймворком.
Обычно нет, и честный ответ даёт именно аудит. У большинства сбоящих приложений есть конкретные, исправимые причины — отсутствующий жизненный цикл соединения, размазанное состояние, утечки в навигации, — с которыми справляется последовательный рефакторинг, пока приложение продолжает релизиться. Изредка кодовая база действительно за пределами экономически разумного ремонта — тогда аудит говорит это письменно, с аргументацией, и разговор превращается в пересборку с ограниченным объёмом. Единственное, чего не стоит принимать ни от кого, — рекомендацию переписать, сделанную до чтения кода.
Доступ к репозиторию, проект, который собирается, и всё, что есть из аккаунтов в сторах, ключей подписи и документации бэкенда, — плюс симптомы так, как вы их видите, простым языком. Недостающие части — норма для спасательных ситуаций; часть аудита при перехвате — установить, что вы на самом деле контролируете, и восстановить то, что возможно. Актуальная продакшен-сборка и доступ к краш-репортингу, если он есть, заметно сокращают диагностику.
Да — это требование к формату работы, а не выражение надежды. Исправления выходят через поэтапные раскатки в порядке серьёзности, так что пользователи чувствуют облегчение в первых же релизах, а приложение сохраняет обычный релизный ритм. Именно так мы стабилизировали живой телемедицинский продукт, не выводя его из сторов. Спасение, требующее выключить продукт, — это пересборка под чужим именем, и мы сказали бы вам это ещё на этапе аудита.
Да, и это всё более частый запрос: сгенерированный прототип находит реальных пользователей и встречается с продакшеном, где быстро всплывают дыры в безопасности, неконтролируемые расходы на API и срезанные углы в архитектуре. Наш аудит AI-кода существует ровно для такого профиля кодовой базы и проходит так же, как любой спасательный аудит: отчёт с находками, план по серьёзности, затем исправления. Сгенерированный код не безнадёжен — он просто ломается по паттернам, которые мы научились искать первыми.

Прочитайте кейс YouMi — спасение, на котором построена эта страница; загляните на страницу аудита AI-кода — про машинерию аудита; или начните с пилларной страницы разработки на Flutter.