Рефакторинг legacy-системы: как менять работающую систему и не сломать её

Тесты на унаследованный код пишут не по требованиям (требований нет), а по фактическому поведению: что система делает сейчас, правильно или нет. Правильность выясняется отдельно. Сначала нужно зафиксировать поведение, иначе после правки нельзя сказать, что изменилось.

Чем фиксируем поведение

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

Швы: где можно резать без риска

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

Что не берёмся делать без страховки

Если проверить поведение нечем (нет данных, нет тестового стенда, расчёт зависит от рукописных исправлений в базе), мы не начинаем правки кода. Сначала создаём среду для проверки. Иногда это составляет половину работы, и обследование показывает это заранее.

Меняем схему базы без остановки: «расширить и сжать»

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

Обновляем платформу ступенями

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

Что делаем с мёртвым кодом

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

Если нужно сначала узнать, можно ли развивать систему и что с ней не так, начинают с аудита кода и архитектуры: он даёт заключение, а не правки. Если система тормозит и вопрос в границах сервисов, очередях и стратегии замены (душитель, вынос границ, переписывание), смотрите микросервисы и высоконагруженные системы. Рефакторинг в нашем понимании занимается внутренним порядком: тесты, связи, схема, платформа.

Если нужно сменить базу данных или операционную систему, это миграция на PostgreSQL или портирование под Astra Linux. Если система стабильна и нужен только присмотр, подойдёт сопровождение ПО. Разбор типовой задачи, когда система осталась без подрядчика, — в разделе «Разборы».