Если система по-прежнему поддерживает важные процессы и хранит ценные данные, полное переписывание не должно быть первой реакцией. Сначала нужно определить, где находится реальное ограничение: во всей архитектуре, одном проблемном модуле, модели данных, интеграции или порядке выпуска изменений.
Разработка с нуля оправдана, когда значимые части нельзя безопасно сохранить или ограничения старого решения мешают достичь важной бизнес-цели. Во многих других случаях лучше начать со стабилизации, замены самого проблемного модуля или поэтапной управляемой миграции.
Окончательное решение требует анализа конкретного кода, данных и рабочих процессов. Возраста приложения и названия технологии для этого недостаточно.
«Давайте перепишем всё» звучит проще, чем есть на самом деле
Старая система может ежедневно создавать сложности. Выпуск изменений занимает много времени, одна исправленная ошибка приводит к другой, а документация давно не отражает реальную работу. Новое приложение обещает порядок, но вместе с техническим беспорядком легко потерять бизнес-правила, которые нигде не записаны, хотя сотрудники и клиенты пользуются ими каждый день.
Необходимо также разобраться в данных, правах доступа, отчётах, интеграциях и исключениях, которые сейчас обрабатываются вручную. Если обнаружить их слишком поздно, новая система может оказаться аккуратнее технически, но хуже подходить компании.
Новый код ценен не потому, что он новый. Он должен решать конкретную задачу: снижать риск, упрощать будущие изменения, повышать стабильность или облегчать работу пользователей.
Четыре возможных направления
| Направление | Когда его стоит рассмотреть | Что необходимо защитить |
|---|---|---|
| Стабилизация и дальнейшее развитие | Основная часть системы работает, а сбои и дорогие изменения сосредоточены в нескольких местах. | Критические процессы, резервные копии, тесты ключевых сценариев, выпуск изменений и видимость ошибок. |
| Поэтапная замена модуля | Один компонент мешает развитию, но остальная часть приложения сохраняет ценность. | Границы данных и интеграций, а также период одновременной работы старого и нового модулей. |
| Управляемая миграция | Старая платформа или модель данных имеют фундаментальные ограничения, но переход можно разделить на этапы. | Сверку данных, порядок переключения процессов, непрерывность работы и возможность вернуться назад. |
| Разработка с нуля | Ценные части невозможно сохранить или их ограничения не позволяют достичь цели. | Полный объём функций, накопленные за годы скрытые правила, перенос данных, параллельную работу и отключение старой системы. |
Таблица помогает упорядочить обсуждение, но не заменяет аудит. Один и тот же симптом, например медленный выпуск изменений, может быть связан с архитектурой, отсутствием тестов, ненадёжным процессом развёртывания или несколькими причинами одновременно.
Четыре вопроса перед выбором
- Правильно ли система по-прежнему обслуживает ключевые процессы и данные?
- Какие части вызывают больше всего сбоев, ручной работы или дорогих исправлений?
- Получает ли используемая технология обновления безопасности и может ли работать в поддерживаемом окружении?
- Можно ли отделять и заменять модули, не останавливая всю компанию?
Если проблема относится к одной области, нет причины автоматически воссоздавать всё приложение. Новая разработка становится более обоснованной, когда систему нельзя надёжно запустить в воспроизводимом окружении, ключевые зависимости больше не поддерживаются, а данные и модули невозможно безопасно разделить.
Что проверить до принятия решения
Оценка не должна ограничиваться исходным кодом. Нужно выяснить:
- какие процессы нельзя прерывать;
- где находятся данные и как выполняется резервное копирование;
- какие внешние системы обмениваются информацией с приложением;
- какие роли и права доступа действительно используются;
- как сейчас устроены тестирование, развёртывание, мониторинг и возврат к предыдущей версии;
- какие временные обходные решения стали частью повседневной работы;
- какой измеримый результат должен дать первый этап.
Без этих ответов легко сравнить стоимость исправления нескольких видимых проблем со стоимостью неполной версии новой системы. Такое сравнение некорректно. Новая реализация должна учитывать миграцию, интеграции, сохранение данных, переходный период и приёмку самых важных процессов.
Когда модернизация разумнее
Поэтапная модернизация имеет прочную основу, если система продолжает работать, содержит ценные данные, используется реальными пользователями и позволяет провести границы между модулями. Тогда сначала можно стабилизировать критические участки, защитить важное поведение тестами и улучшить контроль ошибок.
Затем заменяются компоненты, которые сильнее всего ограничивают компанию. У каждого этапа должны быть собственный объём, критерии приёмки и план возврата. Последующие решения будут опираться на знания о реальной системе, а не только на предположения, сделанные в начале проекта.
Когда имеет смысл разработка с нуля
Новое приложение стоит серьёзно рассмотреть, если текущая платформа больше не поддерживается, модель данных не позволяет реализовать нужное развитие, требования компании принципиально изменились или безопасное разделение старой системы обойдётся дороже её управляемой замены.
Даже в этом случае необязательно переключать всё за один день. Сначала можно перенести один процесс, сравнить результаты и лишь затем расширять объём. Миграция данных, параллельная работа и возможность возврата являются частью проекта, а не задачами, которые добавляют непосредственно перед запуском.
Пример из портфолио: разные этапы развития Tempus
В портфолио Domin Software описаны несколько этапов работ для магазина Tempus. Они включали очистку существующего кода и разработку специальных модулей, обновление платформы и графического оформления, а также миграцию с sStore на PrestaShop с переносом товаров и клиентов.
Это не означает, что каждое приложение должно пройти тот же путь. Пример показывает, что выбор между развитием и переписыванием не обязан быть одним решением на весь срок жизни системы. На одном этапе ценность имеют исправления и дальнейшее развитие, на другом — управляемый переход на новую основу.
Подтверждённый объём работ представлен в портфолио Domin Software. Мы не используем его как доказательство конкретного коммерческого результата или готовый рецепт для другой компании.
Мост вместо одного большого прыжка
Во время серьёзных изменений старая и новая части могут некоторое время работать одновременно. Выбранные процессы направляются в новый модуль, данные переносятся партиями, а результаты сравниваются до расширения объёма. Пользователи могут переходить группами, не меняя всю рабочую среду в один день.
Такой подход соответствует паттерну Strangler Fig, описанному Мартином Фаулером. Он не превращает сложный проект в простой, но помогает снизить риск единовременной замены всего решения и проверять каждый этап.
Где может подойти DominPress
Если изменения касаются публичных страниц, контента, форм или новых веб-модулей, DominPress можно добавить как новый слой без немедленной замены всей внутренней системы компании. Однако это не автоматическое решение для любой старой системы. Выбор должен учитывать процессы, данные, интеграции и план дальнейшей поддержки.
Что указать в первом сообщении
Для первоначального разговора подготовьте:
- краткое описание системы и её пользователей;
- самый важный процесс, который нельзя прерывать;
- конкретную проблему, мешающую развитию или вызывающую ошибки;
- используемую технологию и версию, если они известны;
- список основных интеграций;
- ожидаемый результат первого этапа;
- информацию об актуальных резервных копиях, тестовом окружении и документации.
Не отправляйте пароли, ключи, копию рабочей базы данных или реальные данные клиентов. На первом шаге достаточно описания проблемы и контекста, чтобы отличить точечную задачу от технического обследования или первого этапа модернизации.
Выберем правильное направление для существующей системы
Мы не предполагаем заранее, что приложение необходимо переписать. Сначала определяем, что по-прежнему имеет ценность, что действительно ограничивает компанию и как снизить риск изменений. Возможный объём работ описан на странице модернизации систем.
Чтобы начать с конкретного случая, опишите проблему в существующей системе.