Поделиться
«Код стареет быстрее бизнеса»: почему крупные ИТ-проекты вынуждены переписывать себя
Большинство цифровых сервисов, которыми мы пользуемся каждый день — от интернет-магазинов до корпоративных систем — внешне могут почти не меняться годами. Однако внутри многие из них регулярно проходят сложные технологические обновления: разработчики меняют программные платформы, оптимизируют интерфейсы и иногда фактически переписывают систему заново, при этом продукт продолжает работать и получать новые функции. О том, почему такие технологические миграции становятся неизбежными для крупных ИТ-проектов, CNews рассказал разработчик пользовательских интерфейсов (Senior Frontend Developer) Игорь Сахаров.
CNews: Игорь, вы участвовали в переносе крупного проекта со старого AngularJS на современный Angular (наборы инструментов для разработки веб-приложений), причем разработка новых функций при этом не останавливалась. В какой момент становится понятно, что систему уже нельзя просто поддерживать и нужно менять архитектуру?
Игорь Сахаров: В нашем случае ключевым сигналом стало то, что AngularJS достиг стадии окончания жизненного цикла. Это означает, что фреймворк больше не получает обновлений и исправлений безопасности.
Продолжать использовать такую технологию в долгосрочной перспективе становится рискованно: любые уязвимости могут остаться без исправлений, а совместимость с современными инструментами постепенно ухудшается.
Но бывают и более прикладные признаки того, что проекту требуется миграция. Один из них — проблемы с производительностью.
Например, в старых веб-проектах часто используется библиотека jQuery (популярная программная библиотека для работы с интерфейсом веб-страниц). Со временем отдельные элементы интерфейса начинают работать заметно медленнее: анимации дергаются, интерфейс реагирует с задержкой. Когда начинаешь разбираться, оказывается, что используется устаревший механизм вроде jquery.animate — функции анимации из этой библиотеки.
Проблема в том, что полностью убрать библиотеку часто невозможно — она задействована в других частях системы, например в формах. Получается замкнутый круг: производительность падает, но исправить это точечно нельзя.
В такой ситуации архитектурная миграция становится фактически единственным способом решить проблему.
CNews: Вы использовали гибридный режим, при котором старая и новая версии фреймворка работают одновременно. Какие риски у такого подхода?
Игорь Сахаров: Основной риск — конфликты зависимостей. Когда в одном приложении сосуществуют две технологические платформы, разные части системы могут использовать разные версии библиотек. В результате одна и та же зависимость может вести себя по-разному в разных модулях приложения.
Второй риск связан с передачей данных между частями системы. Когда логика начинает взаимодействовать между двумя фреймворками, иногда возникают неожиданные эффекты: данные передаются не так, как предполагалось, или обновления происходят с задержкой.
Поэтому такие проекты требуют очень аккуратного планирования. Например, если в системе используется сторонняя библиотека, лучше сначала найти все места, где она применяется, и мигрировать их одновременно.
Еще один важный принцип — минимизировать прямое взаимодействие между старой и новой частью приложения. В таких случаях удобно использовать серверную часть системы или backend, как единый источник данных.
CNews: Были ли моменты, когда казалось, что проект может выйти из-под контроля?
Игорь Сахаров: На практике многое зависит от архитектуры процесса. Если перенос делается поэтапно и заранее понятно, какие модули будут обновляться и в какой последовательности, проект остается управляемым.
Гораздо опаснее ситуация, когда система годами накапливает компромиссы и временные решения без общей стратегии. Тогда каждая новая функция добавляет еще один слой сложности.
Миграция в этом смысле — попытка вернуть системе управляемость и сделать архитектуру снова понятной.
CNews: Для бизнеса переписывание системы — это дополнительные расходы. Как объяснить руководству, что такие изменения действительно необходимы?
Игорь Сахаров: Самый понятный аргумент для бизнеса — это пользовательский опыт.
В одном из проектов время первой загрузки страницы без кеша доходило примерно до двадцати секунд. Для современного веб-сервиса это очень много: пользователь просто закрывает страницу.
После анализа стало понятно, что основная проблема связана с размером приложения и способом его загрузки. Чтобы ускорить работу, нужно было уменьшить общий пакет и внедрить отложенную загрузку модулей (lazy loading — механизм, при котором части программы загружаются только в момент, когда они действительно нужны). Но реализовать это в старой архитектуре было невозможно.
После перехода на современный фреймворк время загрузки сократилось примерно до одной-двух секунд. В этот момент становится очевидно, что речь идет не о техническом эксперименте, а о прямом влиянии на пользовательский опыт и бизнес-метрики.
CNews: Насколько сложно разработчику работать на границе технологий и бизнес-интересов?
Игорь Сахаров: Это один из самых сложных аспектов профессии.
Разработчик часто оказывается посредником между технической реальностью и ожиданиями заказчика. Нужно не только реализовать решение, но и объяснить, почему оно именно такое и какие ограничения есть у системы.
Для меня важен принцип прозрачности. Заказчик должен понимать, какие задачи решаются, какие есть технические ограничения и почему определенные решения требуют времени и ресурсов.
Когда коммуникация строится открыто, большинство сложных вопросов решается значительно быстрее.
CNews: Вы часто работаете с миграциями и интеграциями сторонних библиотек. Как появилась такая специализация?
Игорь Сахаров: Во многом это связано с опытом работы с чистым JavaScript (язык программирования для веб-разработки). Когда пишешь проекты без тяжелых фреймворков (программных платформ для разработки), лучше понимаешь, как устроены сами библиотеки и какие механизмы лежат под ними.
Со временем этот опыт начинает работать сам на себя: становится проще анализировать архитектуру проекта и понимать, какие изменения можно внедрить без риска для всей системы.
CNews: Если смотреть шире, почему крупные IT-системы регулярно переписывают себя?
Игорь Сахаров: Потому что технологии развиваются быстрее, чем сами продукты.
Любая архитектура со временем устаревает. Появляются новые требования к безопасности, производительности и масштабируемости. То, что десять лет назад считалось хорошим инженерным решением, сегодня может становиться ограничением для развития продукта.
Если компания хочет продолжать развивать систему, ей приходится периодически обновлять технологический фундамент. Иногда это происходит постепенно — через небольшие изменения архитектуры. Иногда требуется более масштабная миграция.
Но в целом это естественный процесс. Система, которая никогда не меняется, обычно просто перестает развиваться.
CNews: Что, на ваш взгляд, отличает успешную технологическую миграцию от неудачной?
Игорь Сахаров: В первую очередь — понимание цели. Если команда переписывает систему просто потому, что технология устарела или «все так делают», такие проекты часто затягиваются и начинают конкурировать с разработкой новых функций.
Успешная миграция обычно начинается с конкретной проблемы: производительность, масштабируемость, ограничения архитектуры. Тогда становится понятно, какой результат должен получить бизнес.
Второй важный фактор — прозрачность процесса. Заказчик должен понимать, что происходит с продуктом и зачем это делается. Когда техническая команда и бизнес смотрят на задачу одинаково, даже сложные миграции проходят значительно спокойнее.
Короткая ссылка
