Практический кейс: Отладка и миграция legacy-системы в рамках импортозамещения

Импортозамещение в IT — это не просто замена одного программного обеспечения на другое с похожим функционалом. Это сложный процесс миграции, который часто сопровождается глубокой отладкой и рефакторингом унаследованных (legacy) систем. В этом кейсе мы разберем реальный пример переноса системы документооборота с проприетарной зарубежной платформы на стек с открытым кодом (Open Source). Основной вызов заключался не в написании нового кода, а в понимании, воспроизведении и отладке скрытой бизнес-логики старой системы.

Контекст. У клиента — крупного промышленного предприятия — работала система на базе платформы «Х», все поддержка и обновления которой прекратились. Система содержала критически важные модули формирования отчетов, маршрутизации согласований и интеграции с 1С. Исходный код основных модулов был недоступен, только бинарные файлы и база данных. Задача: перенести функционал на новую платформу (был выбран стек: Java Spring Boot + PostgreSQL + Angular), обеспечив полную функциональную идентичность.

Фаза 1: Реверс-инжиниринг и логирование. Поскольку прямого доступа к коду не было, первым шагом стало максимально детальное логирование всех входных и выходных данных старой системы. Мы создали промежуточный прокси-сервер, который фиксировал все HTTP-запросы, параметры, заголовки и ответы. Для работы с базами данных были написаны скрипты, анализирующие триггеры, хранимые процедуры и сложные связи между таблицами. Ключевым инструментом отладки на этом этапе стал Wireshark для анализа сетевого трафика и JD-GUI для предварительного просмотра декомпилированных Java-архивов (в системе были и такие компоненты).

Фаза 2: Воссоздание бизнес-логики и написание тестов. На основе собранных логов мы начали воссоздавать алгоритмы. Самой сложной частью оказался модуль расчета сложных накладных с многоуровневыми скидками и налогами. Старая система давала результат, но алгоритм был неочевиден. Мы применили методику «отладки на расстоянии»: создавали в новой системе тестовые вызовы, сравнивали результат с эталонным от старой системы и итеративно правили алгоритм, пока результаты не совпадали с точностью до копейки. Для этого был написан набор интеграционных тестов на JUnit, где эталонные данные хранились в виде JSON-фикстур.

Фаза 3: Отладка интеграций. Старая система общалась с 1С по устаревшему протоколу на основе COM-объектов. Нужно было не просто повторить, а адаптировать интеграцию под современный REST API 1С или обмен через файлы. Проблема отладки заключалась в асинхронности и неконсистентности данных в 1С. Мы разработали специальный симулятор API 1С, который позволял детерминированно воспроизводить различные сценарии (успех, ошибка, таймаут), что ускорило отладку логики повторов и компенсирующих транзакций (Saga pattern) в новой системе.

Фаза 4: Поэтапный запуск и A/B-тестирование. Полный «биг-бэнг» был слишком рискованным. Мы внедрили канареечные деплои и режим «теневого прогона». Новая система запускалась параллельно со старой, получала те же данные, производила расчеты, но не записывала результаты в основную БД. Специальный мониторинговый дашборд в Grafana в реальном времени сравнивал ключевые метрики (суммы отчетов, время обработки) двух систем и сигнализировал о расхождениях. Это позволило отловить множество пограничных случаев, которые не были выявлены на этапе тестирования.

Итог. Проект занял 14 месяцев. Ключевым уроком стало понимание, что успех импортозамещения legacy-систем на 70% зависит от качественного анализа и отладки существующей логики, а не от написания нового кода. Инструменты реверс-инжиниринга, детальное логирование, симуляторы внешних систем и стратегия параллельного прогона оказались важнее выбора конкретных технологий. Новая система не только полностью заменила старую, но и благодаря современному стеку получила возможность для быстрого развития и масштабирования.