Быстрее, кто играет Халка в кинематографической вселенной Marvel? Если вы сказали, что Марк Руффало, вы в основном правы - Эд Нортон дебютировал с не таким уж веселым зеленым гигантом в Невероятном Халке 2008 года, но Руффало превратился в большую зеленую машину с 2012 года The Мстители.

Вы также можете вспомнить, что объявление о переработке Marvel Studios в 2010 году действительно расстроило фанатов. Они пришли в ужас при мысли о том, что номинированного на «Оскара» Нортона заменит малоизвестный в то время неряшливый инди-актер.

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

Это подводит нас к переделанной дилемме здесь, в Grubhub: замена AngularJS на (это просто) Angular.

История до сих пор…

В 2013 году мы выбрали AngularJS в качестве фреймворка для веб-приложений, потому что считали его лучшим доступным инструментом в то время. В нем были все плюсы: внедрение зависимостей, четкий архитектурный шаблон и двусторонняя привязка данных (в то время это было круто). И мы были не единственными - к 2014 году AngularJS был самым популярным фреймворком для одностраничных приложений (по данным GitHub).

На ринг выходит новый претендент

Примерно через год (или 73 года по JavaScript) появился Facebook и потряс мир JS. В 2015 году они открыли исходный код своей инфраструктуры ReactJS, в которой много чего было, например, разумная парадигма одностороннего потока данных, простая в использовании архитектура и сверхбыстрый механизм рендеринга. Его потрясающая эффективность заставила всех усомниться в том, кого они пригласили на вечеринку, включая, возможно, основную команду AngularJS.

Люди были справедливо соблазнены React. Он представил множество замечательных идей, некоторые из которых исправили некоторые недостатки, присущие AngularJS. Медленный рендеринг страницы? VDOM FTW! Отсутствие предсказуемости? Одностороннее падение микрофона для передачи данных.

Прежде чем мы продолжим, вот краткое объяснение некоторых соглашений об одностраничных приложениях (SPA). SPA - это, по сути, гигантские приложения JavaScript, которые запускаются в браузере. Не так давно большинство разработчиков понимали браузерный JavaScript как причудливые меню и надоедливые всплывающие скрипты. А теперь представьте всплывающий сценарий, который прошел через режим обучения персонажа Кристиана Бейла. В результате вы получаете очень мощный (если не раздутый) набор инструментов, который позволяет разработчикам делать гораздо больше, чем создавать красивые меню, ссылающиеся на другие части сайта. Разработчики могут эффективно создать весь сайт - все на JavaScript.

Старые фреймворки SPA (а-ля AngularJS, EmberJS, KnockoutJS) берут HTML-документ и, используя JavaScript, напрямую вносят изменения в его элементы. Думайте об этом как о том шоу на HGTV, где они берут дом и переставляют его мебель. Это все тот же дом, только… лучше.

Новые фреймворки, такие как ReactJS, похожи на то другое шоу на HGTV, где вместо того, чтобы ремонтировать старый дом, они строят на нем новый. Вместо изменения HTML-документа ReactJS использует нечто, называемое объектной моделью виртуального документа (VDOM), своего рода суперклон реальной объектной модели HTML-документа, которой легче манипулировать. Это как если бы страницу вставили в Матрицу, а разработчик - Нео.

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

AngularJS и другие подобные фреймворки делают упор на шаблон Model View Controller (MVC) или Model View ViewModel (MVVM). Ключевая часть этого шаблона, модель, передается по приложению, и с ней могут происходить самые разные вещи, даже на уровне отображения (то есть двусторонняя привязка данных).

В дополнение к гигиеническим соображениям, безнаказанная передача модели затрудняет отладку и усложняет понимание того, что приложение на самом деле делает во время операции; ни один разработчик не хочет играть в «кто сдвинул мой сыр» с проблемами целостности данных. Знание того, что данные передаются только в одном направлении и через контролируемую цепочку поставок, может значительно облегчить разработку приложений.

Скоро в игре: Angular 2 - Продолжение

Как упоминалось ранее, подход ReactJS произвел впечатление не только на разработчиков. Основная команда AngularJS скорректировала траекторию своего фреймворка, чтобы противостоять ReactJS и решить некоторые внутренние проблемы AngularJS. В 2014 году (да, все в том же году) команда AngularJS объявила о своих планах относительно того, что тогда называли Angular 2, и представила поворот, который заставил бы М. Найт Шьямалан покраснеть.

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

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

Сообщество разработчиков раскололось после анонса. Некоторые в ярости ушли и заявили, что перейдут на ReactJS. Некоторые даже создали свой собственный конкурирующий фреймворк (см. AureliaJS). И, конечно же, некоторые оформили предзаказ на игру и посвятили себя Angular 2 (который теперь называется просто Angular, отказавшись от 2 в пользу семантической схемы управления версиями). .

Тем временем, в Башне Мстителей ...

В Grubhub смятение наших инженеров отразилось на сообществе разработчиков. И хотя некоторые команды в конечном итоге заменили свои проекты AngularJS на React, команда разработчиков потребительского Интернета, которую я возглавляю, была не готова перейти на Angular 2 (или даже на React в этом отношении). Несмотря на то, что у нас были свои оговорки, нас больше всего беспокоила предполагаемая попытка «обновления» - любой проект перезаписи был бы чрезвычайно разрушительным для бизнеса с точки зрения времени и затрат.

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

Мы пытались сгладить любые неровности AngularJS, используя все трюки, которые могли найти. Мы боролись с медленным рендерингом, заменив стандартный процесс создания шаблонов AngularJS библиотекой HyperScript - виртуальной DOM-библиотекой, аналогичной той, что есть в ReactJS. Это позволило страницам загружаться быстрее и значительно улучшило наше воспринимаемое время загрузки, особенно на страницах с большим количеством элементов.

Мы прошли через наше приложение с мелкими зубьями и удалили как можно больше двусторонней привязки, чтобы справиться с печально известными проблемами цикла дайджеста AngularJS. Как упоминалось ранее, двустороннее крепление казалось действительно крутым в то время - как кефаль, вымытые кислотой джинсы или светодиодные фонари на ходовой части Honda Accord 2005 года выпуска. Но уродливая правда о неконтролируемом обнаружении изменений быстро поражает всех, кроме самых упорных разработчиков. Устранив как можно больше двусторонней привязки, мы не только значительно улучшили отзывчивость сайта, но и стали лучше спать по ночам, зная, что наше приложение не является программным эквивалентом модного повтора 80-х, который пошел не так.

В течение почти двух лет (или 73 года по сравнению с JavaScript) мы изо всех сил старались извлечь из нашего приложения AngularJS максимальную производительность. В результате бизнес-показатели приложения (конверсия, показатель отказов и др.) Были надежными и соответствовали ожиданиям или даже превосходили их. Тем не менее, время шло, и реальность работы в рамках заимствованного времени и с начальным объявлением об окончании срока службы начала устанавливаться. Нам нужно было спланировать наш следующий шаг, иначе мы застряли в чем-то, что практически не поддерживалось сообществом. и с которым никто не захочет работать.

И поскольку официальная премьера Angular 2 состоялась в 2016 году, а последующие итерации - позже (на момент публикации этой статьи Angular находится в версии 5), нашей команде искренне понравилось, как это получилось. Такие вещи, как рендеринг на стороне сервера из коробки, использование TypeScript и внутренние улучшения производительности, на самом деле очень полезны и потенциально могут добавить намного больше изюминки в наше приложение.

Marvel решила бросить Нортона и пережить гнев фанатов, потому что они считали, что Руффало лучший актер в долгосрочной перспективе. Точно так же мы считаем, что новый Angular - это ваш классический «шаг назад \ два шага вперед» и часть плана основной команды Angular по созданию более богатой экосистемы, которая поможет разработчикам создавать масштабируемые высокопроизводительные (а не только веб-приложения). Мы приветствуем новую версию фреймворка Руффало и принимаем его как настоящего Angular.

Предварительный заказ специального выпуска игры (и всех DLC)

В середине 2017 года мы запланировали наш собственный «Заказ 66» для существующего приложения AngularJS. Мы бы удалили наше текущее приложение на 500 тыс. Строк, пропатченное обезьяной, и заменили бы его крашеным в шерсти Angular 4 (версия на тот момент… да, мы знаем, что это чертовски запутанно), которое принесет нам все преимущества фреймворк нового поколения, создающий лучший опыт как для пользователя, так и для разработчика.

О, и мы бы построили его и выпустим примерно через месяц.

Спойлер: мы сделали это

Ну, не ровно через месяц, но достаточно близко. Примерно за то время, которое требуется для написания и утверждения запроса на перенос в некоторых компаниях, мы полностью перестроили наше приложение AngularJS. Команда из десяти инженеров переписала каждый компонент, директиву и службу устаревшего приложения AngularJS в эквивалентную конструкцию Angular 4. Кроме того, мы продолжали выпускать обновления для устаревшего приложения (примерно два в неделю), включая исправления ошибок и незначительные улучшения.

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

Но для ленивых вот TL; DR:

Мы написали скрипт, который сделает большую часть работы;)

Хотите узнать, как мы готовились к обновлению? Прочтите сообщение Эрика Цая: Скоро Angular: подготовьте обновление.

Хотите узнать больше о возможностях нашей команды? Посетите страницу вакансий в Grubhub.