Почему?

В прошлом году команда инженеров Panorama решила выбрать интерфейсный фреймворк. До этого наши приложения были чисто Ruby on Rails и использовали JavaScript только при необходимости. Мы решили перейти на интерфейсный фреймворк по нескольким причинам:

  • Надежность - мы чувствовали, что наши веб-приложения, хотя обычно внутренне непротиворечивы, кажутся довольно доморощенными. Мы бы предпочли построить их в соответствии с практикой более широкого сообщества javascript.
  • Производительность. Хотя серверная часть может быть быстрой, нам все чаще приходилось создавать пользовательский интерфейс для больших и больших наборов данных, что ограничивало использование серверной рендеринга HTML.
  • Возможность повторного использования - мы достигли некоторого повторного использования за счет использования частичных представлений Rails, но они все еще создавали множество шаблонов, особенно для компонентов пользовательского интерфейса и сложной логики JS.
  • Наем. В ходе собеседований с инженерами у нас были доказательства того, что очень опытные фронтенд-инженеры сочли очень плохим знаком, если у нас все еще не было доминирующего фронтенд-стека.

План

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

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

Рамки и рубрики

Чтобы выбрать фреймворки для изучения, мы пришли к идеям, основанным на отраслевых стандартах и ​​на том, над чем инженеры обычно были заинтересованы. Мы решили исследовать React, Vue.js, Stimulus, Polymer Project и нативные веб-компоненты.

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

Первоначальное расследование

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

В некоторых областях результаты были совершенно другими. У Vue.js и React есть сильные экосистемы, такие как использование Vuex и Redux для состояния и Jest для модульных тестов. Они оба достаточно зрелые, поэтому мы не ожидаем серьезных изменений, когда при обновлении будет ощущаться использование совершенно новой структуры. Наконец, у них обоих большие сообщества, в том числе популярные местные встречи и даже конференции. Таким образом, мы решили создать прототип обоих этих фреймворков, чтобы принять окончательное решение.

Прототип

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

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

Борьба и успехи

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

В течение следующих нескольких недель мы постепенно меняли нашу тактику, чтобы добиться прогресса в прототипе. Каждая группа поняла, что было бы лучше выделить время для парного программирования, что дает несколько преимуществ:

  • Время было заблокировано, чтобы было легче отойти от обычной работы отряда.
  • Только один человек в каждый день должен был все настроить и работать.
  • Было легче работать, пока один человек управлял кодом, а другой мог исследовать, как работает фреймворк.

Хотя это помогло, через несколько недель мы все еще были разочарованы тем прогрессом, которого не добились. Час - не так много времени, чтобы разобраться в кодировании, особенно с незнакомой технологией. Мы решили, что нам нужны большие блоки времени, поэтому мы запланировали несколько больших блоков времени, которые мы все могли бы использовать для достижения прогресса. Эти дни привели к значительному прогрессу в работе над прототипами, что помогло нам как группе решить, что обе платформы кажутся возможными вариантами. Пора было назвать прототипы готовыми.

Тогда что?

Осознав, что любая из этих рамок удовлетворит наши потребности, мы изучили инженеров, чтобы выяснить их предпочтения и выяснить, есть ли что-то еще, что нужно учесть в нашем решении. Мы спросили инженеров, предпочитают ли они Vue.js или React, насколько сильным было это предпочтение и есть ли у других возможность поделиться опытом. С 21 ответом результаты опроса не привели к явному фавориту.

Получив эти результаты, рабочая группа вернулась к обсуждению вариантов. Зная, что любой из них удовлетворит наши потребности, мы вернулись к нашим первоначальным исследованиям и прототипам, чтобы глубоко понять, какая структура будет лучше. Мы отметили, что Vue.js немного проще изучить. Мы также оценили, что технологический стек, который идет вместе с ним, был достаточно стандартизирован в отрасли, поэтому мы не ожидали более сложных решений о том, как проводить модульное тестирование или объединять код. Кроме того, мы предвидели еще одну сложную задачу - начать развертывание новой структуры. Поскольку Vue.js имел небольшое преимущество в нашем опросе, мы были рады предложить этот фреймворк, и еще больше инженеров его горячо поддержали.

Поскольку инженерные решения принимаются коллективно, у нас был последний шаг, чтобы завершить Vue.js в качестве нашей основы выбора - согласие остальной команды инженеров. К счастью, наши исследования, прототипы и принятие окончательных решений были легко понятны инженерам, и вся команда согласилась двигаться дальше с Vue.js.

Вы заинтересованы в том, чтобы увидеть, куда нас завел Vue.js, и принять участие в будущих технологических решениях? "Мы нанимаем"!