Старая система работает, но каждое изменение в ней занимает недели, разработчиков, которые ее понимают, осталось полтора, а на любой вопрос звучит «там лучше не трогать». Знакомая ситуация, и решение в ней обычно формулируют как выбор: чинить дальше или переписать с нуля.
Оба полюса плохие. Переписывание с нуля — самый рискованный сценарий в разработке. Бесконечный ремонт — самый дорогой. Работает третий путь.
Постепенная замена
Смысл в том, что новая система растет рядом со старой и по кускам забирает у нее работу. Перед обеими стоит маршрутизатор, который решает, куда отправить запрос. Пользователь не замечает переезда.
Почему переписывание с нуля почти всегда проваливается
- Старая система знает больше, чем документация. В ней зашиты сотни частных случаев, накопленных за годы. Половину из них никто не вспомнит, пока новая система не начнет работать неправильно.
- Два года без новых возможностей. Пока идет переписывание, бизнес не может получить ни одного изменения. Через год начинают править старую систему параллельно, и проект удваивается.
- Момент переключения. Запуск новой системы одним днем — это день, когда может остановиться все. Откатиться назад после переноса данных сложно.
- Оценка всегда занижена. «Мы знаем, что нужно, ведь система уже есть» — самое обманчивое чувство в разработке. Знание того, что делает система, и знание того, как она это делает, — разные вещи.
Когда чинить дальше разумно
Не всякая старая система требует замены. Признаки, что ремонт выгоднее.
- Изменения нужны редко, а работает она стабильно. Старость сама по себе не проблема.
- Технологии устарели, но люди, которые их знают, есть и будут.
- Данные доступны и структура понятна — значит, ее можно интегрировать с новым, не переписывая.
- Проблема локализована в одном месте. Тогда переезжает одно место, а не система.
Как понять, что пора
Четвертый признак не измеряется, но самый честный: каждое обсуждение новой возможности начинается с фразы «в текущей системе это невозможно».
Как выглядит постепенная замена на практике
- Поставить маршрутизатор перед системой. Пока он просто пропускает все в старую. Это техническая подготовка, невидимая пользователям.
- Выбрать первый кусок. Тот, который меняется чаще всего и меньше всего связан с остальным. Обычно это не самый важный модуль, и это правильно.
- Сделать его в новой системе и переключить. С возможностью вернуть обратно одним переключателем.
- Наладить обмен данными между старой и новой. Пока обе живут, данные должны сходиться. Это основная сложность подхода, и ее надо принять как цену.
- Повторять, пока в старой не останется ничего важного. Последний кусок иногда так и остается — и это нормально, если он работает.
Честная оговорка: постепенная замена сложнее в проектировании и требует жить с двумя системами какое-то время. Взамен вы не останавливаете бизнес и в любой момент можете прекратить, оставшись с работающим результатом.
Как считать деньги
Сравнивать надо не стоимость переписывания со стоимостью ремонта, а три года владения по каждому варианту.
Вторая строка в среднем варианте — то, что делает подход честным. Жить с двумя системами действительно дороже, чем с одной. Но это плата за то, что бизнес не останавливается и что от проекта можно отказаться, не потеряв все.
Что делать с данными старой системы
Отдельный вопрос, который решается раньше технических.
- Что переносить. Обычно справочники и открытые документы. Историю за десять лет переносить в новую структуру дорого и чаще всего не нужно.
- Где хранить историю. Старая система в режиме чтения или выгрузка в отдельное хранилище. Второе надежнее: система без поддержки однажды перестанет запускаться.
- Как отвечать на вопросы по прошлым периодам. Должен быть способ найти документ трехлетней давности, даже если он не переехал.
- Сроки хранения. По части документов они установлены законом, и это влияет на то, когда старую систему можно выключить совсем.
Где здесь ИИ
При работе со старой системой модели закрывают самую неприятную часть — чтение чужого кода без документации.
Восстановление логики. Что именно делает эта процедура на две тысячи строк, какие в ней частные случаи. Раньше это была археология на недели, теперь это часы, а человек проверяет выводы.
Описание модели данных. Таблицы с полями вроде flag1 и dt2 превращаются в человеческое описание, по которому можно проектировать новое.
Перенос данных. Сопоставление старых справочников с новой структурой, разбор значений из текстовых полей, поиск аномалий в исторических данных.
Чего ИИ не делает — не принимает решение, какой кусок переносить первым, и не отвечает за корректность восстановленной логики. Каждое правило, найденное в старом коде, надо подтвердить у того, кто знает бизнес.
Разберем вашу систему и предложим порядок
Расскажите, что за система, что в ней болит и в каком состоянии доступ к коду и данным. В ответ — оценка, что чинится, что переезжает и в каком порядке, с первым куском, который можно сделать за недели.
Если система в порядке и дело в организации работ, так и будет сказано.