Перехід з 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: зберігайте ідентифікацію, дозволи, договори, ідемпотентність, помилки, поведінку застарілих збірок і правила першоджерела між версіями, що працюють одночасно.
• Перевіряйте й випускайте сам перехід: охопіть навігацію та життєвий цикл між середовищами, справжні браузери й дані, доступність, швидкодію, поступове відкриття, пороги, повернення та видалення старого шляху.