Новый сценарий в Android-приложении без техдолга: 6 шагов от задачи до релиза

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

Почему новый сценарий в старом приложении превращается в долг 🧩

Пятница, четыре часа дня. Торговому представителю на складе клиента нужно принять паллету по QR-коду, а в приложении такого сценария нет. Отдел продаж просит добавить его к понедельнику. Разработчик открывает экран заказа: в нём свалено всё сразу, от запроса на сервер и расчёта скидок до отрисовки кнопок. Чистого места для нового кода нет, срок горит, поэтому он копирует экран и переделывает копию под приёмку.

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

Так и копится долг. Обычно за ним стоят такие ярлыки:

• ✓копия существующего экрана с правками под новую задачу;
• ✓булевы флаги в общем классе состояния вроде «если приёмка, показать это», из-за которых экран растёт, пока никто не решается его открыть;
• ✓бизнес-логика прямо в Activity или Fragment, которую нельзя проверить тестом без запуска эмулятора.

Это стоит денег, причём вполне конкретных. Заказ с неверной скидкой уходит в 1С, и расхождение находят при закрытии месяца. Релиз откладывается, потому что тестировщик не знает, что ещё задела правка. Когда уходит единственный разработчик, знавший код, приложение замораживают: новые сценарии не добавляют, пока его не перепишут целиком. А переписывание с нуля обходится как новое приложение, у нас такая разработка стартует от 500 000 ₽.

Как исправить подход: какой способ встраивания выбрать

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

Для сценария, который проживёт дольше квартала, подходит третий вариант. Копию экрана оставьте для пилота, который заранее решено удалить.

Как добавить сценарий без техдолга: шесть шагов 🛠

Шаг 1. Составьте карту того, что сценарий заденет

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

Отдельной строкой запишите, какие данные собирает сценарий. Если это геолокация сотрудников, фото документов или телефоны клиентов, проверьте требования 152-ФЗ до разработки. Персональные данные граждан России записывают и хранят в базах на территории РФ, и переделывать хранилище после релиза дороже, чем заложить его сразу.

Шаг 2. Выделите сценарий в отдельный модуль

Новый код живёт в собственном Gradle-модуле, например feature-receiving. Он зависит от общего ядра приложения, а ядро о нём ничего не знает. Старый код обращается к сценарию через одну точку входа: маршрут навигации и пару интерфейсов. Если сценарий придётся убрать или переделать, вы удалите один модуль и не будете искать следы по всему проекту.

Шаг 3. Выносите общее, а не копируйте

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

Шаг 4. Закрепите тестами контракт и критичные пути

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

Шаг 5. Выпускайте за фича-флагом

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

Шаг 6. Оставьте след для следующего разработчика

Запишите в README модуля, зачем сценарий сделан именно так, где его границы и что он вызывает. Подключите сбор крашей и аналитику, например AppMetrica, чтобы увидеть проблему раньше пользователя. Через год вы сами не вспомните, почему выбрали эту схему, а новому подрядчику не придётся гадать.

Что делать, если ошибка повторяется 🔁

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

1. ✓Напишите тест, который воспроизводит ошибку, и только потом чините. Пока тест красный, ошибка не исправлена. Когда он зелёный, она не вернётся незамеченной.
2. ✓Найдите все копии логики поиском по проекту: по названию формулы, константе, тексту ошибки. Исправление в одном месте из трёх даёт ту же ошибку через месяц.
3. ✓Сведите копии в одну функцию или класс и переведите на него все экраны.
4. ✓Не затевайте переписывание целиком. Переносите в отдельные модули по одному сценарию каждый раз, когда всё равно его дорабатываете. Долг гасится по частям, а приложение остаётся в работе.

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

Как предотвратить долг при следующих доработках

Долг растёт от привычки. Если каждую задачу закрывают по принципу «лишь бы работало», через год набирается то, что описано выше. Что помогает:

• ✓Добавьте в определение «готово» три условия: тесты на новую логику, фича-флаг и запись о принятом решении. Задача без них не закрыта.
• ✓Закрепите направление зависимостей на уровне сборки. Если модуль сценария зависит от ядра, Gradle не даст ядру подключить этот модуль в ответ.
• ✓Включите в CI статический анализ, например Android Lint и detekt, и запретите сборку при новых замечаниях.
• ✓Ведите отдельный список техдолга и назначьте у него владельца. Долг без владельца не гасится.
• ✓Показывайте код нового модуля второму разработчику, пока модуль мал и его можно прочесть за вечер.
• ✓Версионируйте обмен с сервером. Сотрудники в поле обновляют приложение не сразу, и старые версии должны продолжать работать после выхода нового сценария.

Сколько стоит доработка и как её делает ukved.ru 💬

Цену доработки определяет состояние кода, поэтому вслепую по телефону мы её не называем. Порядок такой: смотрим проект и вашу 1С, составляем карту зависимостей, предлагаем способ встраивания из таблицы выше и после этого называем срок и смету. Для ориентира: разработка мобильного приложения с нуля у нас начинается от 500 000 ₽, а расценки по остальным услугам собраны на странице цен и тарифов.

Отличие от обычной студии простое: мы внедряем и сопровождаем 1С сами. Контракт обмена между приложением и учётной системой согласуем внутри одной команды, а не передаём между двумя подрядчиками, каждый из которых уверен, что проблема на стороне другого. Если вам нужно приложение для клиентов или дилеров с заказами в 1С, посмотрите готовый подход на странице B2B-приложения с 1С.

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

Сколько занимает добавление нового сценария в готовое Android-приложение?

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

Можно ли доработать приложение, которое написал другой подрядчик?

Да, если у вас есть исходный код и доступ к репозиторию, сборке и ключам подписи. Мы изучаем проект, оцениваем качество кода и предлагаем способ встраивания сценария. Если исходников нет, дорабатывать нечего: остаётся делать новое приложение, а разработка у нас начинается от 500 000 ₽.

Что такое фича-флаг и нужен ли он в B2B-приложении?

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

Когда лучше переписать Android-приложение, а не дорабатывать?

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

Сколько стоит добавить сценарий в существующее приложение?

Цена зависит от состояния кода и от того, что сценарий затрагивает: обмен с 1С, локальную базу, права доступа. Поэтому мы называем её после аудита, а не по телефону. Для ориентира: разработка нового мобильного приложения у нас стоит от 500 000 ₽, доработка существующего считается отдельной сметой.