Если ваш проект был разработан много лет назад и его становится все дороже и дороже поддерживать, внедрение новых функций занимает необъяснимо много времени, а разработчики все чаще жалуются на какой-то “техдолг” – вы имеете дело с legacy-кодом. И если ничего не предпринять, в какой-то момент затраты на поддержку в конечном итоге могут превысить выгоду, которую приносит система.
Проблемы legacy-кода
Сам по себе legacy-код не является проблемой, если система функционирует без сбоев. Проблема заключается в поиске разработчиков, способных поддерживать такой код. С течением времени это становится все сложнее делать, особенно если речь идет о специфических технологиях. Поиск разработчиков для такого продукта может быть не только долгим, но и очень затратным, поскольку редкие специалисты на рынке стоят дороже.
Другая проблема связана с возможностью устаревания технологий, на которых основан код. Это может привести к потере работоспособности системы. Например, популярная технология Flash в определенный момент устарела. В 2012 Adobe, занимавшаяся ее разработкой, объявила о прекращении поддержки Flash в 2012 году, а в конце 2020 года поддержка полностью прекратилась. В результате продукты, зависимые от Flash, вынуждены были либо перейти на другие платформы, либо разработать нужные компоненты с нуля.
Таким образом, у каждого продукта есть свой срок жизни. Невозможно разработать систему, которая будет работать бесконечно без обновлений и поддержки. Продукт, оставленный без поддержки, со временем устареет настолько, что перестанет быть пригодным для использования. Поэтому систему с legacy-кодом нужно обновлять.
Подходы к обновлению legacy-кода
При обновлении legacy-кода важно минимизировать влияние на бизнес, поскольку система уже функционирует и имеет активных пользователей. Это означает, что обновление системы должно происходить постепенно, компонент за компонентом.
Если по каким-то причинам постепенное обновление невозможно, приоритетной становится поддержка работоспособности текущей системы с одновременным началом разработки новой версии. Параллельная разработка позволит эффективно переключить пользователей на новую версию в будущем. При этом важно учесть вопросы переноса данных, чтобы обеспечить плавный переход для пользователей и избежать потери информации.
После завершения разработки новой версии, некоторое время можно поддерживать обе системы параллельно. Это дает возможность части пользователей оценить и протестировать новую версию, предоставив обратную связь. На основе этой обратной связи можно доработать новую версию и постепенно перевести всех пользователей на более современную версию.
Подводим итоги
Каждый продукт имеет свой срок годности. Если система долгое время не обновлялась и накопила большое количество legacy-кода, её обновление необходимо.
Обновлять систему можно постепенно, компонент за компонентом, или параллельно разрабатывать новую версию. Оба подхода помогают сохранить продукт, внедрить новые технологии и стандарты, минимизируя риски для бизнеса.
Если у вашей системы те же проблемы с legacy-кодом – мы предлагаем бесплатный аудит системы с подробным отчетом и рекомендациями по решению имеющихся проблем.
Забронируйте звонок или напишите нам
Подробно про аудит системы можно почитать здесь
Комментарии