Переход с AngularJS на Angular: стратегия поэтапной миграции рабочего продукта

Переход с AngularJS на Angular заменяет гораздо больше, чем средство построения интерфейса. Меняются запуск приложения, ответственность за компоненты, внедрение зависимостей, маршрутизация, формы, состояние, шаблоны, обнаружение изменений, средства сборки и тестирования, сторонние библиотеки, поведение в браузерах, выпускные сборки и знания, необходимые для сопровождения клиентской части. Воспринимайте это как переход продукта с сохранением совместимых пользовательских сценариев, а не как уборку в хранилище кода.

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

Цель состоит не в воспроизведении каждого шаблона AngularJS на языке TypeScript. Модели компонентов, шаблонов, реактивного взаимодействия, зависимостей и сборки в Angular побуждают к другим границам. Сначала выясните, от какого прежнего поведения действительно зависят пользователи, служба поддержки, интеграции и аналитика. Затем переносите целые сценарии в архитектуру, которую команда сможет безопасно развивать, и удаляйте каждый устаревший путь, как только его замена докажет надёжность в рабочей среде.

Разберитесь, почему сопровождение AngularJS дорожает

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

Сам видимый программный каркас — лишь часть ограничения. Устаревшие цепочки сборки, неподдерживаемые средства запуска тестов, старые библиотеки интерфейса, хрупкие стили CSS, недоступные компоненты, недокументированные обходные решения для браузеров и договоры серверной части, сформированные вокруг прежних экранов, могут быть опаснее AngularJS. Найдите настоящую причину: медленную обратную связь, дефекты в рабочей системе, трудности найма, угрозы безопасности, предел быстродействия или неспособность достичь продуктового результата. Без такого диагноза миграция сохранит самые дорогие части под названием современного пакета.

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

Выбирайте между переписыванием и поэтапным переходом по уровню риска

Поэтапная миграция обычно позволяет и дальше развивать продукт и превращает неопределённость в череду небольших решений. Сначала можно придать коду AngularJS ясные компонентные границы, обновить сборку и тесты, отделить клиенты API и состояние, а затем внедрить Angular на стабильной границе оболочки, маршрута или функциональной области. Каждый перенесённый сквозной сценарий охватывает интерфейс, состояние, доступ к данным, тесты, аналитику, доступность, выпуск и ответственность; завершение означает удаление его реализации на AngularJS.

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

Сравнивайте варианты по календарному времени, способности одновременно мигрировать и создавать новые возможности, стоимости двух сред выполнения, угрозам безопасности, неудобствам для клиентов, обучению, доказательствам тестирования, замене сторонних составляющих, частоте выпусков и восстановлению. Не сводите выбор к ложной дилемме «переписать всё» или «ничего не менять». Лучшим следующим шагом может стать стабилизация действующей системы, выделение нового маршрута, замена одной возможности или удаление неиспользуемого поведения.

Проектируйте гибридное сосуществование как временный мост

Во время перехода AngularJS и Angular могут работать в одном гибридном приложении. Официальный мост обновления позволяет запустить обе среды и передавать выбранные службы и компоненты в обоих направлениях. Это механизм миграции, а не целевая архитектура. Запишите, кто отвечает за запуск, маршрутизацию, обработку ошибок, общие зависимости, глобальные стили, распространение изменений и завершение работы. Установите правило: новые продуктовые возможности создаются в целевой архитектуре, если для исключения нет отдельного согласования.

Ослабьте связи старого кода до пересечения моста. Преобразуйте подходящие директивы в компоненты с явными входными и выходными данными, перенесите логику контроллеров в службы с ясной ответственностью или предметные функции, уберите неявное общение через родительскую область видимости, изолируйте непосредственные изменения DOM и определите стабильные клиенты API. Пересекайте границу сред через узкие договоры. Каждая зависимость, переданная между AngularJS и Angular, усложняет запуск, обнаружение изменений, диагностику и последующее удаление моста.

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

Переносите компоненты и маршруты с чёткой ответственностью

Составьте перечень модулей, контроллеров, директив, шаблонов, фильтров, служб, маршрутов, предварительной загрузки данных, проверок доступа, форм, валидаторов, библиотек интерфейса, глобальных стилей и прямых интеграций с DOM в AngularJS. Свяжите их с пользовательскими сценариями и ответственными. Сначала выбирайте компоненты с ограниченным потоком данных и небольшим числом зависимостей от среды, но первый фрагмент должен охватывать содержательное взаимодействие, API, форму, аналитику и путь выпуска, а не только доказывать, что статичная карточка отображается.

Для каждого компонента определите входные и выходные данные, состояния, поведение доступности, содержимое, загрузку и пустое состояние, проверку, разрешения, ошибки и восстановление. Осознанно сохраняйте точки подключения автоматизации и смысл аналитических событий. Заменяйте общие визуальные основы через версионную систему дизайна, которая временно будет обслуживать обе среды, вместо создания двух не связанных библиотек компонентов. Визуального сходства недостаточно, если ухудшились управление с клавиатуры, фокус, работа программы чтения с экрана, задержка или поведение при отказе.

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

Сохраняйте правила состояния и API между двумя средами выполнения

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

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

Не копируйте каждую службу AngularJS в глобальный единственный экземпляр Angular. Отделите предметную и прикладную логику от браузера и программного каркаса, а затем открывайте её через узкие типизированные интерфейсы. Используйте реактивные потоки только там, где поток действительно соответствует природе задачи; неуправляемые подписки и общие изменяемые источники данных могут воспроизвести прежние проблемы с областью видимости. Для каждого асинхронного сценария определите отмену, работу с запоздалыми ответами, конкурентность, очистку и ответственного за ошибки.

Проверяйте весь переход, а не только новые компоненты

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

Проверяйте характерные для гибридной системы отказы: порядок запуска, зависимости, переданные между двумя средами, распространение изменений AngularJS и Angular, навигацию через границу, обновление сеанса, отложенную загрузку, дублирующиеся запросы, очистку обработчиков событий, историю браузера, прямые ссылки, несколько вкладок, устаревшие файлы и частичное развёртывание. Выявляйте утечки памяти и дублирующиеся обработчики повторной навигацией. Измеряйте размер сборки, загрузку и скорость взаимодействия на показательных устройствах и сетях, а не только на компьютере разработчика.

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

Выпускайте маршрут за маршрутом, не останавливая развитие продукта

Управляйте продуктовой работой в одном упорядоченном перечне приоритетов. Выделите в плане чётко определённое время команды для миграции и, где возможно, сочетайте модернизацию с настоящим продуктовым сценарием вместо воссоздания неиспользуемых экранов. Считайте работу завершённой, когда поведение Angular принято, телеметрия поступает из рабочей среды, эксплуатационная ответственность определена, а код, тесты, маршруты, зависимости, записи моста и стили AngularJS удалены. Подсчёт созданных компонентов Angular вознаграждает добавление, скрывая незавершённое удаление старой системы.

Создавайте однозначно прослеживаемые сборки через проверенную автоматизацию и испытывайте среды, близкие к рабочей. Открывайте целые маршруты или группы пользователей постепенно, применяя явные средства управления. Заранее согласуйте пороги для ошибок JavaScript, неудачных вызовов API, задержки, скорости взаимодействия, завершения сценариев, нарушений доступности, обращений в поддержку и показателей бизнеса. Разделяйте наблюдения по среде выполнения, маршруту, версии, браузеру, устройству, региону и группе. Назначьте человека, уполномоченного остановить выпуск.

Возврат может означать направление сценария обратно в AngularJS, отключение возможности, восстановление совместимого поведения серверной части или исправление следующей версией. Он усложняется после создания пользователями новых данных или изменения договоров серверной части, поэтому границу безопасного восстановления нужно определить до выпуска. После стабилизации быстро удалите старый путь, согласуйте срочные изменения, обновите эксплуатационные инструкции и ответственных и убедитесь, что следующий выпуск больше не зависит от знаний о прежней системе.

Когда полезна независимая помощь с переходом на Angular

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

Оценивайте подрядчика по рабочим доказательствам: гибридному запуску, передаче составляющих между средами, переносу маршрутов, изоляции состояния, совместимости серверной части, доступности, быстродействию, стратегии тестирования, управлению развёртыванием, телеметрии, удалению старых путей и обновлению программного каркаса. Убедитесь, что внутренние инженеры участвуют в проектировании, проверке, выпуске и работе с происшествиями. Успех означает, что клиент может безопасно продолжать модернизацию и сопровождать конечный продукт на Angular без постоянной зависимости от подрядчика.

• Докажите ограничение старой системы: свяжите доказательства по поддержке, безопасности, стоимости изменений, дефектам, быстродействию, доступности или найму с измеримым результатом миграции и ответственным.
• Выберите наименьшую ответственную стратегию: сравните стабилизацию, поэтапный перенос сценариев и переписывание по нарушению работы продукта, цене двух сред, доказательствам, восстановлению и общему сроку.
• Ограничьте гибридный мост: назначьте ответственных за запуск, маршрутизацию, пересечение зависимостей, состояние, стили, ошибки, быстродействие, телеметрию и удаление; определите условие завершения.
• Переносите целые маршруты и сценарии: вместе перемещайте интерфейс, состояние, API, аналитику, доступность, тесты, выпуск и поддержку, а затем удаляйте прежнюю регистрацию.
• Назначьте единый источник истины для состояния и API: сохраняйте идентификацию, разрешения, договоры, идемпотентность, ошибки, поведение устаревших сборок и правила первоисточника между версиями, работающими одновременно.
• Проверяйте и выпускайте сам переход: охватите навигацию и жизненный цикл между средами, настоящие браузеры и данные, доступность, быстродействие, постепенное открытие, пороги, возврат и удаление старого пути.