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

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

Отрасль: фармаконадзор

Задача: принять чужое приложение, вывести его из технического тупика и развивать дальше

Старт: апрель 2025

Что было: мобильное приложение на закрытой платформе и серверная часть, унаследованные от предыдущей команды

Что стало: приложение на актуальной кроссплатформенной технологии, число внешних зависимостей сокращено с двадцати двух до четырёх

Роль Nabla Lab: приём проекта, миграция, развитие

Что нам передали

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

Такой проект принимают не по документации, а по коду: он и есть единственный источник правды о том, как система себя ведёт.

Почему это был тупик

Приложение работало, и со стороны казалось, что проблемы нет. Проблема была, и складывалась она из трёх частей.

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

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

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

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

Разбор чужого кода

Первая работа была не в написании кода, а в чтении.

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

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

Это самая недооценённая часть работы с наследством. Её нельзя ускорить, её нельзя пропустить, и именно на ней ломаются проекты, где подрядчик берётся переписать чужое приложение, не прочитав его.

Переезд без потери поведения

Приложение перевезли на актуальный кроссплатформенный каркас от того же производителя — преемника закрытой платформы. Целевые сборки собираются под свежие версии Android и iOS.

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

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

Двадцать две зависимости против четырёх

Отдельный результат, которым мы довольны.

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

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

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

Новое — параллельно с переездом

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

За первый этап приложение получило:

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

Раздел о компаниях, чьи интересы организация представляет по вопросам фармаконадзора, с уполномоченными и контактными лицами и странами, где ведётся деятельность.

Информационную поддержку — перечень нормативных правовых актов отрасли под рукой у специалиста.

Архив документации — мастер-файл системы фармаконадзора и стандартные операционные процедуры в личном кабинете.

Разделы по аудитам и инспекциям, управлению рисками и проектам изменений инструкций по медицинскому применению.

Запрос информации прямо из приложения — специалист отправляет вопрос, не выходя в почту.

Отчёт по мониторингу на стороне клиента.

Приложение внутри своей экосистемы

Отдельная особенность этого проекта: приложение живёт не само по себе.

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

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

Что получил заказчик

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

Почему это важно для вас

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

Мы умеем принимать такое наследство. Не «перепишем всё с нуля» - это дорого, долго и почти всегда заканчивается плохо, — а разобрать, вывести из тупика и продолжать развивать, не останавливая работу.

Расскажите, что у вас за система и в каком она состоянии, — посмотрим, что с ней делать.