Перевод legacy-системы на low-code: конвертер, линтер, эталон

Перевод legacy-системы на low-code платформу разумно делать по схеме «конвертер плюс линтер плюс эталон»: машина переносит однозначно описанное, линтер ловит ошибки переноса, эталон задаёт образец результата и основу для приёмки. Тогда у проекта есть измеримая готовность, а не ощущение «вроде всё перенесли». Ниже объясняю, как это устроено у меня, когда переписывать, когда обновлять и где автоматический перенос должен остановиться. Опираюсь на свой кейс перевод legacy-системы на low-code, новых фактов о нём не добавляю.

Переписывать или обновлять

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

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

Сравнение вариантов по полной стоимости за несколько лет разобрано в статье своя разработка или готовое. Про то, где хватает конструктора, а где нужен разработчик, есть материал ноукод против кода.

Как устроен конвертер

Конвертер разбирает описание экрана в старой платформе и собирает эквивалент в новой. Переносятся формы, поля, типы данных, связи и базовые проверки, то есть всё, что описано формально и потому переносится однозначно.

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

Линтер и что он проверяет

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

Линтер у меня это набор правил, по которым проверяется результат. Остались ли обязательные поля обязательными. Нет ли полей без типа. Совпадают ли связи между сущностями. Не потерялись ли значения справочников. Не остались ли заглушки, которые конвертер вставил при неоднозначности. Линтер ничего не чинит, он показывает. Заодно он даёт объективный ответ на вопрос «сколько сделано»: число непройденных правил вместо ощущений.

Эталон: образец и приёмка

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

Он же служит основой приёмки. Готовый экран сравнивают с эталоном, чужие представления о хорошем в приёмке не участвуют. Спор «мне кажется, тут надо иначе» превращается в проверяемую фразу «в эталоне сделано так, здесь отличается, объясни почему». Как вообще принимать работу, написано в статье приёмка работы подрядчика.

Как проверить, что поведение не изменилось

Линтер сверяет структуру. Поведение он проверить не может, поэтому к трём инструментам я добавляю четвёртый, эталонные сценарии. Это уже моя методика, к кейсу выше она относится как расширение, его описанием она не является.

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

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

Риски и пределы автоматического переноса

Три места, где я останавливаю автоматику намеренно.

• Бизнес-правила без описания. Если правило не записано формально, машина его не перенесёт и начнёт угадывать. Угаданное правило худший вид дефекта: система работает, но неправильно, и это видно только по последствиям.
• Деньги и права доступа. Цена ошибки здесь такова, что экономия на ручной проверке не оправдана при любом объёме.
• Интерфейс сложных экранов. Машинный перенос даёт формально корректный, но неудобный результат: порядок полей, группировка, поведение при ошибке. То, что люди делали годами по привычке, конвертер воспроизвести не может.

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

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

Как я это делаю

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

Если вы не уверены, нужен ли перенос вообще, начните с разбора и автоматизации процессов: сначала решим, что переносить, потом как. О самих платформах у меня есть разборы: Budibase для внутренних приложений и Appsmith для админ-панелей.

Сколько это стоит

Точную стоимость переноса называю после разбора выборки, заранее по числу экранов цену не считаю. Ориентиры по моему прайсу:

• Технический аудит старой системы: что в ней есть, что переносится машиной, какие риски, от 50 000 ₽, от 1 недели.
• Автоматизация процессов и документов, в том числе перенос модулей, от 60 000 ₽, от 2 недель.
• Разработка по часам для доработок и точечных задач от 3 000 ₽/час.
• Поддержка после запуска: исправления, доработки, обновления, мониторинг, от 20 000 ₽/мес.

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

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

Какую долю системы удаётся перенести машиной?

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

Можно ли обойтись без конвертера и нанять больше людей?

На небольшом объёме можно, иногда это даже дешевле. С ростом числа исполнителей растёт разнобой: каждый переносит по-своему. Конвертер здесь гарантирует единообразие.

Что делать, если описания старой системы нет вообще?

Тогда сначала нужен аудит и сбор знаний у людей и из данных, а перенос идёт потом. Для таких систем я не обещаю высокую долю автоматического переноса.

Что останется у нас после проекта?

Конвертер, линтер, эталон и сценарии проверки. Без них следующая доработка снова превращается в риск.

Коротко о главном

Конвертер самая заметная часть перевода legacy на low-code, но не самая важная. Линтер показывает ошибки переноса, эталон задаёт образец, эталонные сценарии проверяют, что поведение сохранилось. Для небольшой системы всё это лишнее, для большой однородной окупается. Границы автоматики я называю заранее: бизнес-правила без описания, деньги и права, сложные экраны остаются людям.

Если у вас система, которую страшно трогать и дорого поддерживать, напишите мне в Telegram с кодовым словом «КОНВЕРТЕР»: разберу выборку экранов и скажу честно, что переносится машиной, а что требует человека.