Перепроектирование устаревших систем без остановки работы

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

Перепроектирование — это способ заменить систему, не выбросив то, ради чего она существует. И сделать это не одним прыжком, а так, чтобы компания продолжала работать все это время.

Почему «переписать с нуля» обычно проваливается

• Никто не знает всех требований. Они не в документации, а в коде, который писали десять лет. Переписывание с чистого листа гарантированно теряет часть из них, и обнаруживается это уже в бою.
• Два года без результата. Пока пишется новая система, старая живет и требует изменений. Команда раздваивается, сроки едут, интерес у руководства заканчивается раньше проекта.
• Запуск одним днем. Переключение всей компании на новую систему за выходные — сценарий с высоким риском и без пути назад.
• Новая система повторяет старые ошибки. Ее делают по образцу того, что было, потому что разбираться в процессах никто не стал. Получается тот же дом, только с новой проводкой.
• Данные не переехали. История в старом формате, справочники с дублями, десять лет документов. Эту работу почти всегда недооценивают.

Как мы это делаем

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

1. Разбираемся, что система делает на самом деле. Не по документации, а по коду, данным и разговорам с пользователями. Отдельно выясняем, чем реально пользуются, а что мертво: обычно мертвого больше трети.
2. Вытаскиваем ценное. Правила расчета, исключения, накопленные справочники и историю. Это то, что делает вашу систему вашей, и это переносится обязательно.
3. Отрезаем первый кусок. Функциональный блок, который можно вынести наружу и связать со старой системой обменом. Обычно начинают с того, что меняется чаще всего.
4. Работаем параллельно. Новый кусок в бою, старый пока доступен. Данные общие, расхождений нет — это проверяется сверкой, а не на слово.
5. Повторяем. Следующий блок, потом следующий. С каждым шагом старой системы остается меньше, а страха меняться — тоже.
6. Отключаем старую. Когда в ней не осталось ничего живого. К этому моменту это уже нерискованное административное действие, а не событие.

Что переносим, а что оставляем

Второй список составляется вместе с вами и это самая полезная часть проекта. Обычно выясняется, что треть функциональности можно не повторять — и это сразу сокращает бюджет и срок.

Где здесь искусственный интеллект

Именно в этой задаче модели изменили экономику сильнее всего.

• Восстановление требований из кода. Разбор старой системы и описание того, что она делает, включая правила, которых нет ни в одном документе. Раньше это была работа на месяцы.
• Перенос логики между языками. Старый код на устаревшем языке превращается в черновик на современном. Именно черновик: результат проверяет и доводит разработчик, но начинать не с нуля — большая разница.
• Восстановление документации. Описание структуры данных и связей по самой базе, когда документации нет вообще.
• Разбор и чистка данных при переносе. Дубли справочников, разные написания, битые связи — поиск кандидатов на исправление.
• Генерация тестов на старое поведение. Чтобы убедиться, что новая часть считает так же, как старая. Это ключевая страховка всего проекта.

С какими системами приходят

• Самописная система на устаревшем стеке. Работает десять лет, автор уволился или один держит ее в голове. Технологии больше не поддерживаются, найти разработчика трудно и дорого.
• Сильно доработанная коробка. Продукт купили, потом дописали столько, что обновляться стало нельзя. Формально это чужой продукт, фактически — ваша система без поддержки производителя.
• Набор из Excel и мелких программ. Каждый кусок кто-то когда-то сделал под свою задачу. Формально системы нет, фактически бизнес работает именно на этом, и заменить это одним продуктом не выходит.
• Ушедшая зарубежная платформа. Лицензии не продлеваются, обновлений нет, поддержки нет. Здесь важно перенести не «все, что было», а то, чем реально пользовались, — обычно это заметно меньше.
• Система, купленная вместе с бизнесом. Досталась в наследство, никто не знает, как она устроена, а бизнес на ней работает. Начинать приходится с технического аудита.

Как не потерять логику, которой нет в документах

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

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

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

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

Сроки и стоимость

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

Когда менять не надо

Честный раздел, потому что замена — дорогое решение.

Если система работает, ее меняют редко и она не мешает бизнесу расти, то жалобы разработчиков на «плохой код» — недостаточное основание. Некрасивый код, который никто не трогает, ничего не стоит.

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

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

Что остается у вас

Код новой системы в вашем репозитории, описание перенесенных правил расчета — то, что раньше существовало только внутри старого кода, теперь записано. Данные с историей, перенесенные и сверенные. Инструкции по развертыванию и по работе.

И возможность останавливаться. План по блокам устроен так, что после каждого шага система целостна: если у вас изменились приоритеты или закончился бюджет, вы остаетесь с работающим результатом, а не с недостроенным зданием.

Дальше по теме