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