Стек Personal Capital Web - Часть II

Привет! Прошло некоторое время, и мы хотели сообщить вам, что веб-команда Personal Capital все еще жива и отвечает на запросы с низкой задержкой.

Наш блог наконец-то переехал, и мы рады этому. На самом деле, мы настолько воодушевлены, что захотели проследить за тем, что произошло за 900 дней с тех пор, как мы создали наш последний пост и сейчас.

В этом посте мы расскажем обо всех изменениях, которые мы внесли в наш стек, о том, почему мы внесли эти изменения, а также расскажем о некоторых хороших и плохих вещах, которые эти изменения принесли нам.

Начнем с техники (в конце концов, возможно, именно поэтому вы здесь).

Интерфейсный стек

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

Это позволяет нам запускать локальную версию приложения веб-сайта без необходимости запускать внутренний сервер локально. Это также дает дополнительное преимущество - просмотр наших файлов и запуск локальных сборок Webpack при их изменении (горячая перезагрузка, детка!). Как вы, наверное, уже заметили, счастье разработчика во многом зависит от того, насколько легко работать в среде, поэтому мы впервые изменились.

Мы перешли с RequireJS на Webpack. Это была огромная веха. Некоторые из наблюдаемых преимуществ включают:

• Уменьшено время перезагрузки в разработке.
• Интеллектуальное объединение, которое включает встряхивание дерева, что приводит к уменьшению размера пакета для статических ресурсов CSS и JS.
• Фрагменты скрипта. Они запрашиваются по запросу, что ускоряет нашу загрузку.
• Оптимизация процесса сборки и сборки. В настоящее время мы объединяем несколько разных приложений из одних и тех же источников. Раньше чего-то подобного было трудно достичь; пришлось обновить многие скрипты, чтобы собрать такие варианты. Это сделало процесс медленным и рискованным. Теперь у нас есть четко определенные конфигурации Webpack, которые позволяют нам создавать всевозможные комбинации, просто касаясь файлов конфигурации.
• Расширенная расширяемость. Теперь мы можем интегрироваться с инструментами с открытым исходным кодом, уже разработанными сообществом (например, с отчетами о покрытии, диаграммами зависимостей и т. Д.).

Одностраничное приложение и HTML

Наши внутренние сервисы написаны на Java. Команда разработчиков серверов проделала большую работу по переводу нашей старой монолитной архитектуры на микросервисы. Скоро они опубликуют статью об этом, так что следите за обновлениями.

Уровень нашего веб-сервиса обрабатывает запросы к API и передает данные в SPA, управляемый Backbone и Angular. Backbone по-прежнему является ключевой частью нашего стека, но мы переходим с Angular на React. Каждый новый компонент, который мы разработали за последние три года, написан на React. Это позволило нам:

• Легко повторно используйте компоненты. Сам React очень хорошо работает с нашей существующей базовой архитектурой. Достичь функциональности очень просто, передав реквизиты, если вы правильно передаете методы и события жизненного цикла компонента.
• Некоторое время мы используем шаблон представления контейнера ‹-›. Нам действительно нравится, как он абстрагирует различные проблемы, предоставляя нашим компонентам другой уровень возможности повторного использования (например, мы можем повторно использовать одну и ту же диаграмму с разными входными данными, поступающими из разных API-интерфейсов, и сделать ее по-разному, передав реквизиты). Теперь мы думаем о том, чтобы перейти от этого шаблона к хукам React, которые только что вышли из духовки и пахнут свежеиспеченным печеньем. В настоящий момент мы выясняем, как интегрировать нашу платформу тестирования с этим новым шаблоном, поскольку фермент еще не позволяет это сделать.
• Из-за предыдущего пункта наш рабочий процесс разработки полностью изменился. Мы интегрировали Сборник рассказов. Storybook - это первое место, где мы разрабатываем компоненты. Мы начинаем с этого, чтобы гарантировать, что наши поделки полностью абстрагируются от приложения, что дает нам более высокий уровень уверенности при разработке действительно многоразовых презентационных компонентов.

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

Из-за того, что Storybook разрабатывает компоненты изолированно, веб-инженеры не зависят от внутренних разработок, что позволяет нам работать в тандеме, чтобы предоставить функцию, не зависимо друг от друга.

Со времени нашей последней публикации наши технологии рендеринга HTML перешли с Angular и Handlebars на React.

Стили

В основном мы перешли от всего, что мы использовали, например, Bootstrap, к нашим собственным стилям, основанным на Inuit. Мы продолжаем использовать БЭМ в качестве соглашения об именах и KSS для нашей документации по стилю.

Как и Storybook, мы также создали руководство по стилю, которое содержит большинство основных компонентов HTML с нашими стилями и вариациями. Это хорошая отправная точка для новых людей, которые могут проверить наши методы стилизации, названия классов и брендинг. Есть планы на будущее по переносу всех документов KSS в сборник рассказов, но у нас пока нет на это времени.

Визуализация данных

D3 - это наша библиотека визуализации данных, и так было с тех пор, как Raphael.js замедлил темпы своего развития почти до такой степени, что его не обслуживают.

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

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

Вы можете ознакомиться с более подробной информацией о наших реализациях D3 здесь.

Тестирование

На смену Mocha, Sinon, Karma и Chai пришли Jest и Enzyme. Их интеграция с React естественна, и мы много работали над переносом старого теста на Jest и Enzyme.

Порт - это отдельная история. Обычно мы проводим около двух раз в месяц в боевой комнате, чтобы провести то, что мы называем «сеансом шуток». Все это время мы все работаем над большим списком тестовых файлов, которые необходимо перенести.

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

Вот как выглядит часть скрипта:

sed -i ‘’ ‘s/to.equal/toBe/g’ $NEWFILE
sed -i ‘’ ‘s/to.be.equal/toBe/g’ $NEWFILE
sed -i ‘’ ‘s/to.contain/toContain/g’ $NEWFILE
sed -i ‘’ ‘s/to.not.equal/not.toBe/g’ $NEWFILE
sed -i ‘’ ‘s/to.be.false/toBe\(false\)/g’ $NEWFILE
sed -i ‘’ ‘s/to.be.true/toBe\(true\)/g’ $NEWFILE

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

За время, которое мы использовали шутку и энзим, мы обнаружили:

• Значительное сокращение времени тестирования. Поскольку тесты теперь могут выполняться параллельно, это ускоряет все, от наших git push hooks, которые выполняет модульный тест, до непрерывной сборки, которая происходит на уровне CI-сервера. Фактически, мы только что объединили некоторый код, чтобы запустить тест, на который повлияли наши изменения, в ловушке фиксации. Это ускоряет процесс проверки. В коде используется параметр Jest« - changedSince », если вы не знали об этом, обязательно стоит взглянуть.
• Это позволило нам тестировать компоненты в полной изоляции, не полагаясь ни на что иное, кроме того, что мы тестируем. Имитационные функции работают прямо из коробки и не требуют настройки.
• Простота реализации поощряет TDD. Это происходит естественно. Чем проще выполнить тесты, тем больше вам будет нравится их писать.
• Готовые отчеты о покрытии - это то, чего мы раньше даже не искали и поняли, что это ключ к повышению качества.
• Моментальное тестирование позволяет нам убедиться, что ничего не было обновлено волшебным образом нашими изменениями, что дает нам более высокий уровень уверенности при выпуске кода.
• Интеграция IDE делает разработку тестов настолько простой, что каждый с нетерпением ждет возможности писать модульные тесты. Горячая перезагрузка дает вам немедленную обратную связь при использовании TDD.

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

CI

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

Подведение итогов

Для справки, все, что здесь не упоминалось, остается прежним. Например. для управления версиями мы все еще используем Git, и наши спринты длятся одну экстремальную неделю.

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

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

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

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

Ваше здоровье!