Не каждую устаревшую систему нужно сразу переписывать. Часто в ней уже живут процессы, данные, интеграции и знания сотрудников, которые нельзя «выключить на время проекта».
Модернизация — это изменение уже работающего приложения при сохранении нужной бизнесу логики. Общий контур разработки описан на странице разработки программного обеспечения. Здесь — как принимать решение по существующей системе, а не как создавать приложение с нуля. Заказная разработка нового контура — отдельная задача: заказная разработка ПО.
Признаки, что систему пора менять
Имеет смысл обсуждать модернизацию, если несколько пунктов совпадают:
- новое требование занимает несоразмерно много времени из-за хрупкой архитектуры;
- исходный код, документация или среда сборки частично утрачены;
- обновление платформы, библиотеки или связанной системы стало рискованным;
- интеграции держатся на ручных выгрузках и разовых скриптах;
- сотрудники обходят систему, потому что доверяют ей меньше, чем таблице;
- найти причину сбоя можно только у одного человека;
- стоимость изменения сопоставима с риском остановки процесса.
Один устаревший интерфейс сам по себе ещё не доказывает, что систему нужно разбирать. Иногда достаточно сопровождения, обучения и наведения порядка в выпусках. Если проблема именно в поддержке после запуска, смотрите сопровождение программного обеспечения.
Сначала разбираем действующее приложение
Универсальной замены любой устаревшей системы нет. До плана работ нужно понять конкретное приложение.
На обследовании фиксируют:
- какие процессы система закрывает сегодня;
- где хранятся данные и какие из них нельзя потерять;
- какие интеграции живые, какие формальные, какие уже не работают;
- как собирают, выпускают и откатывают изменения;
- какие части кода трогать опасно, а какие давно не используются;
- какие ограничения задаёт бизнес: окна простоя, регуляторика, сезонность, зависимость от поставщика;
- кто владеет кодом, лицензиями и доступом к контурам.
Результат обследования — карта ограничений и вариантов. Процент снижения технического долга появляется только если его можно измерить на этой системе.
Если исходников, стенда или прав на систему нет, сначала оценивают, можно ли вообще принять её в работу. Наличие работающего интерфейса для этого недостаточно.
Какие есть пути, кроме полной замены
После обследования обычно сравнивают несколько стратегий. Их можно сочетать, но нельзя смешивать в одну фразу «просто модернизируем».
Постепенное приведение в порядок
Меняют внутреннее устройство модуля, не меняя внешнее поведение. Имеет смысл, когда логика в целом верная, а мешает хрупкость кода, тестов или сборки.
Замена отдельных компонентов
Выносят или заменяют одну часть: отчёты, обмен, интерфейс одной роли, узкий сервис. Остальная система продолжает работать.
Перенос на другую платформу
Меняют среду выполнения, способ поставки или связанную инфраструктуру, сохраняя прикладную логику. Это отдельный риск: совместимость, лицензии, данные и восстановления. Возможность переноса зависит от текущей платформы и оценивается отдельно.
Пересмотр архитектуры
Меняют границы модулей, модель данных или способ обмена, потому что текущая нарезка больше не выдерживает развитие. Это не равно «обязательно разрезать систему на множество независимых сервисов».
Замена системы
Оправдана, когда развивать текущее приложение дороже и рискованнее, чем построить новый контур и перенести данные. Тогда проект ближе к заказной разработке плюс миграция, а не к косметическому обновлению.
Готовый продукт имеет смысл проверить до решения «пишем замену». Если сценарий закрывает CTRL или штатная интеграция уже существующей системы, новый код может быть лишним. Обмен между старым и новым контуром описывает страница интеграций и API.
Как жить со старой и новой частью одновременно
Большинство рабочих систем нельзя остановить «до конца проекта». Нужен план сосуществования:
- что остаётся в старом контуре на время перехода;
- какие операции идут параллельно в двух местах;
- как сходятся справочники и идентификаторы;
- кто в какой момент считается эталоном данных;
- как выглядит переключение и как возвращаются назад, если проверка не прошла.
Миграция данных — отдельная работа, а не последний вечер перед запуском. На общем уровне заранее разбирают дубли, пустые поля, расхождения справочников, исторические записи и то, что делать с операциями, которые начались в старой системе и должны закончиться в новой.
Проверки включают не только новый интерфейс. Нужны регрессия ключевых сценариев, повторная обработка обмена, наблюдение за сбоями после переключения и понятный откат. Допустимое окно работ, включая простой, и критерий успеха согласуются по конкретной операции.
Модернизация или новая система
Выбор делают по фактам обследования, а не по возрасту кода.
К развитию текущего решения склоняются, если:
- бизнес-логика в целом верная и задокументирована хотя бы у людей, которые ей пользуются;
- данные и интеграции понятны;
- узкие места локализованы;
- процесс нельзя надолго останавливать.
К новой системе склоняются, если:
- исходное приложение нельзя безопасно собрать и сопровождать;
- модель данных или процесс уже не соответствуют работе компании;
- каждое изменение ломает несвязанные участки;
- права на код, лицензии или контур не позволяют вести контролируемую работу.
Между этими полюсами часто оказывается поэтапная замена частей. Главное — не принять решение по демонстрации нового интерфейса, пока не ясны данные, обмен и критерий отката.
Что зависит от обследования
После разбора действующего приложения определяют, что входит в ближайший этап:
- можно ли развивать текущую систему по частям или нужен новый контур;
- нужна ли смена платформы и какие у неё ограничения по лицензиям, данным и восстановлению;
- какое окно простоя допустимо и как выглядит откат;
- какие узкие места закрывает этот этап, а какие остаются на потом;
- принимается ли сторонний код в сопровождение.
Числовой эффект для бизнеса, переход без простоя и заранее заданный процент снижения технического долга входят в план только если их можно обеспечить и измерить на этой системе.
В проектах Burger King Belarus и MOSTRA-GROUP SoftTech выполнял интеграционные задачи и специализированную разработку. Состав работ по конкретной унаследованной системе определяется обследованием этого приложения.
Что нужно для оценки
Для первого разбора полезно описать:
- какое приложение работает сейчас и какую операцию оно закрывает;
- что именно мешает: скорость изменений, сбои, интеграции, данные, сопровождение;
- есть ли исходный код, документация, тестовый контур и права на них;
- какие системы связаны с приложением;
- какое окно простоя допустимо, а какое нет;
- что должно сохраниться обязательно, а что можно отложить.
После этого можно сравнить сопровождение, поэтапное изменение, замену части или новую разработку.
Обсудить развитие существующей системы →
Состав работ специализированной команды — на stdev.by.