Эксперимент с Морфеусом - Часть I

Эксперимент с Морфеусом - Часть I

Предпосылка:

Здесь, в Upside, мы любим отсылки к фильмам. Фактически, мы назвали наше первое приложение, ориентированное на клиентов, Neo, как дань уважения серии фильмов Матрица. Однако, когда пришло время поэкспериментировать с предлагаемыми нами продуктами, мы решили, что нужно новое кодовое имя. Оставаясь верными нашей теме Матрицы, мы решили, что нет лучшего имени для нашего эксперимента, чем имя человека, который размышлял:

«Вы верите, что дышите этим воздухом?»

Да, это было по памяти ... Я совершенно не смотрел Матрицу снова, чтобы вытащить эту цитату!

В Neo мы предлагали комплексное предложение для отелей и авиабилетов для экономии денег. В Morpheus, однако, мы предложили нечто иное - предложение по-прежнему было пакетным для экономии средств, но оно также превосходило предыдущую версию с опцией совместного использования. Клиенты могли выбрать любые два из трех или все три компонента пакета и получить огромную экономию!

К сожалению, с Морфеусом пришлось столкнуться не только с бизнес-задачами, но и с сложной инженерной головоломкой. Neo был приложением AngularJS 1.X с `$ scope` и контроллерами, распределенными по всей его полноте, но мы не использовали все преимущества компонентов AngularJS, представленных в версии 1.5. Учитывая это, было бы лучше, если бы мы продолжили экосистему Angular или реализовали что-то совершенно другое?

Разработчики всегда понимали, что Морфеус не будет следующей итерацией Neo. Таким образом, он легко стал примером использования новых технологий. Кроме того, при сборке нашего нового приложения Voltron было необходимо обобщить уроки, извлеченные из Морфеуса. Да, мы наконец отказались от кодовых имен Matrix, но в конечном итоге нам нужно было диверсифицировать!

Вопросы о технологиях, на которые нужно ответить с помощью Morpheus:

До Morpheus обсуждение привело нас к началу двух возможных путей: присоединиться к экосистеме React или перейти на Angular. Выбор пути потребовал рассмотрения вопросов по следующим направлениям:

Хотим ли мы написать машинописный текст?

Можем ли мы сделать масштабное преобразование нашего приложения (в React или Angular)?

Будет ли нашим младшим инженерам легче писать Typescript или JSX?

Будет ли легко нанять инженеров для приложения Angular 1.5, которое находится в процессе миграции, или отреагировать?

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

Экосистема React требует, чтобы мы выбирали между стандартным React или Preact. Коллективно мы решили попробовать Preact, учитывая его оптимальный размер (https://github.com/developit/preact/wiki/Differences-to-React). Хотя у обоих были свои плюсы и минусы, наш выбор Material-UI в конечном итоге нам помог (https://www.material-ui.com/#/). Material-UI имел зависимости React, которые мы не могли исправить с помощью Preact.

Находки Морфеуса:

Morpheus был SPA (одностраничным приложением), в котором не использовались маршруты. Мы использовали React, Material-UI, Aphrodite и Redux, все они были связаны с Webpack 2. Будучи прославленной формой, мы знали, что можем использовать фреймворк для нашего приложения, ориентированного на клиента, с компонентами формы, чтобы быстро двигаться. Сначала мы оценили материальный дизайн Lite с Preact и Material-UI с React. Затем мы решили добавить Material-UI, чтобы не изобретать колесо с точки зрения создания компонентов ввода.

Возвращая Neo в перспективу, двум инженерам потребовалось более двух месяцев, чтобы построить его скелет и добавить наши функциональные тесты (любая первая поездка на Uber и презентация пакета). Мы жили в мире Канбана, где мы ежедневно принимали решения о том, какие ошибки и функции следует исправлять. Компоненты Redux и Reusable - две основные причины, по которым мы смогли решить эту проблему.

Redux - это архитектурная модель, которая требует декларативного способа управления состоянием. На следующей веб-странице представлены дополнительные пояснения: (https://redux.js.org/docs/introduction/ThreePrinciples.html). Я знаю, что технически нам ничто не мешает делать Redux с Angular. Не обращая внимания на неортодоксальные методы, на которые мы способны, и учитывая нашу проблему привлечения новых разработчиков, принято использовать React с Redux, а не Angular с Redux.

Redux значительно упростил отладку, так как состояние было только для чтения, а мутации происходили внутри редукторов. Кроме того, мы включили реагировать на инструменты разработчика (https://github.com/facebook/react-devtools) в разработке и на этапе, чтобы наш QA мог загружать состояние и позволять нам воспроизводить их действия до момента ошибки. Это сокращает типичное устранение неполадок, типичное для которых инженеры говорят что-то вроде: «Это не ошибка, потому что я не могу ее воспроизвести». Его можно не только воспроизвести, но и определить, какое действие его нарушило.

"Эй, я только встретил тебя. И это безумие. Но вот ваш state.json. Так что поправишь свой код, может быть? "

Многоразовые компоненты - это то, над чем мы много работали. Понятно, что этого не могло бы случиться без помощи наших дизайнеров UI / UX, которые работали в Sketch. Если ваши дизайнеры предлагают участие, следующая веб-страница содержит отличное руководство по получению выдающихся повторно используемых компонентов: (https://airbnb.design/painting-with-code/). Дисциплинированный подход к использованию повторно используемого компонента означал, что новые страницы, способные повторно использовать представления, было намного проще реализовать, поскольку мы могли использовать один и тот же компонент снова и снова.

К сожалению, не все прошло гладко. Во-первых, несмотря на все преимущества, которые мы получили с компонентами ввода Material-UI, автозаполнение и выбор даты были тусклыми. У нас был большой набор требований к функциям автозаполнения и выбора даты в поиске O&D (Origin and Destination). Систему Material-UI было нелегко расширить и настроить. Более того, оказалось, что автозаполнение в Material-UI в основном включает все возможные компоненты, что сильно раздувает их во время импорта.

Ранее я намекнул на Voltron - прозвище нашего нового приложения, объединяющего Нео и Морфеус. В следующем сообщении блога я расскажу об уроках, которые мы извлекли из Морфеуса, и о том, как мы применили их к Вольтрону.

Если этот пост вызвал у вас интерес, ознакомьтесь с нашими открытыми вакансиями инженера и начните работать с Лином в Upside сегодня: https://upsd.io/2w8h5gL