Порт расчётной программы на Qt: порядок шагов и проверка на каждом

Почему не переписывают целиком

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

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

Порядок шагов

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

Исходная сборка сохраняется отдельной веткой или тегом: она остаётся эталоном до конца работы.

Что дают тесты

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

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

Что остаётся за рамками

Порт не добавляет проверок, которых не было в исходной программе. Новые элементы, новые нормы и просмотрщик результатов — отдельные этапы со своими критериями. Обещать «новую программу к дате» до того, как ядро сверено, нельзя.

Ограничения

Сверка с аналитикой не доказывает соответствие нормам. Она доказывает, что реализация считает то, что заявлено. Нормативная проверка — отдельная работа с отдельным подтверждением.