Старое ПО: обновить или переписать?

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

И тогда возникает вопрос: чинить старое или выбросить и написать новое?

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

Почему «перепишем всё заново» так соблазнительно

Читать старый код тяжело, писать новый — приятно. Новый проект обещает чистый лист: современные технологии, аккуратная структура, всё то, что в старом сделано неправильно.

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

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

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

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

• Движущаяся цель. Пока строится новая система, старая не стоит на месте. Бизнесу нужны изменения, и их приходится делать в двух местах — или не делать в старой вовсе, что раздражает пользователей.
• Долгий период без пользы. Месяцы работы, результат которой пользователь не видит. Если бюджет или терпение заканчиваются раньше, остаются недостроенная новая система и всё та же старая.
• Перенос данных. Данные за десять лет всегда грязнее, чем кажется: битые записи, дубли клиентов, поля, которые используются не по назначению.
• Всё или ничего. В один день происходит переключение, и если что-то не работает, вернуться некуда.

Что значит поэтапная модернизация

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

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

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

Честные критерии: когда обновлять, а когда писать заново

Ответ зависит от пяти вещей.

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

Качество кода. Старый — не значит плохой. Аккуратно написанный десять лет назад код часто хорошо поддаётся обновлению. Но если в нём всё перемешано — запросы к базе посреди HTML, одна и та же логика скопирована в десять мест, — каждый шаг будет дорогим.

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

Бюджет и сроки. Поэтапную модернизацию можно разбить на этапы и приостановить. Новая разработка обычно требует всей суммы прежде, чем что-то попадёт к пользователям.

Риск. Если простой приложения стоит денег или останавливает работу людей, поэтапный путь почти всегда безопаснее.

Когда новая разработка действительно дешевле

Бывают случаи, когда я сам скажу, что обновлять не стоит:

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

Даже тогда старую систему стоит проанализировать до начала новой — как раз чтобы записать скрытые бизнес-правила.

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

С чего я начинаю

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

Подробнее о том, что и как я делаю, — на странице модернизации ПО.

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

Нужно ли останавливать приложение на время модернизации?

Как правило, нет. Работа идёт в отдельной среде, а рабочая версия заменяется только после того, как новая протестирована. Переключение короткое и запланированное.

Что, если нет ни первого разработчика, ни документации?

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

Можно ли потом развивать приложение дальше?

Да, в этом и цель. Когда основа современная и покрыта тестами, новые функции добавляются так же, как в новое приложение.