Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Привет, «Хабр», меня зовут Иван Матвиенко, я несколько лет отвечал за web-технологии в Mango Office, а теперь занимаю должность руководителя направления разработки.
В статье хочу рассказать, как мы в Mango подошли к выбору единой технологии для фронтенда, с какими трудностями столкнулись и что в конце концов из этого вышло. Забегая вперед, скажу, что наш окончательный выбор пал на Angular.
История началась в уже далеком 2016 году. На тот момент основными технологиями были jQuery и библиотека виджетов jQuery UI, которые использовались в нашем самом крупном web-приложении: Личном кабинете Mango Office. Еще один внутренний продукт был написан на ExtJS. Кроме того, некоторые команды экспериментировали с React и AngularJS. Однако использование этих фреймворков и библиотек носило хаотичный характер, и выбор конкретного подхода оставался на усмотрение команды. А о повторном использовании наработок одной команды в другой и речи не было. В связи с этой неопределенностью назрел вопрос унификации стека и выбора технологии для фронта, с которой мы будем жить долгое время.
Выбор технологии
Выбор технологии мы начали с формирования списка требований со стороны продуктовых и технических подразделений. В опросе участвовали отделы продуктов, бизнес-анализа, системного анализа, разработки и тестирования. Первичный список критериев состоял из 31 одного пункта, после отбрасывания не влияющих на выбор осталось 19. Из них 12 были техническими и 7 — от бизнеса. Затем мы попросили подразделения расставить вес критериев по важности. Усреднив, получили вес каждого критерия.
Итоговый список:
Критерий | Вес |
Кросплатформенность. Работа в приложениях на десктопах, смартфонах, планшетах, на платформах Android, iOS, Windows Phone. Работа с touch-устройствами | 8,3 % |
Производительность фреймворка при большом количестве данных | 8,3 % |
Легкая реализация кастомных элементов слоя представления | 6,8 % |
Полноценная документация | 6,3 % |
Базовое быстродействие (без нагрузки в виде большого количества данных) | 6,3 % |
Большая компонентная база | 6,3 % |
Доступность специалистов на рынке | 6,3 % |
Перспективы развития в горизонте 5-10 лет. Риск заморозки работы над фреймворком минимален | 5,9 % |
Наличие инструментов отладка исходного кода, лёгкость локализации ошибок | 5,8 % |
Возможность реализации слоя представления в виде HTML-верстки | 5,6 % |
Низкий порог вхождения для новых сотрудников | 5,5 % |
Наличие механизмов для реализации unit- и авто-тестирования | 5,3 % |
Развитое сообщество | 5,0 % |
Развитая высокоуровневая базовая модель данных инструмента, наличие высокоуровневых шаблонов | 3,8 % |
Отсутствие необходимости программисту работы с DOM-моделью | 3,5 % |
Поддержка стандарта JavaScript ES6+ и TypeScript | 3,5 % |
Низкие трудозатраты при необходимости реализации нестандартных компонентов | 3,4 % |
Локализация приложения в различные иностранные языки | 2,7 % |
Отсутствие ограничивающих лицензий | 1,5 % |
Сейчас читателю часть критериев может показаться бесполезными, но семь лет назад они были актуальны.
Следующим шагом стало составление списка фреймворков и библиотек для сравнения. В него, с одной стороны, вошли уже используемые в компании, с другой, — лидеры рынка на тот момент. Часть исключили по блокирующим критериям: ограничениям лицензий, непригодности для решения наших задач и другим.
Что в итоге получилось:
AngularJS;
Angular 2;
Backbone;
ExtJS;
React+Backbone;
React+Redux.
От jQuery собирались уходить, поэтому в сравнение он не попал. Также в списке нет Vue. В те годы фреймворк был еще мало распространен, нам не хватало промышленных примеров удачного использования для его рассмотрения. Кроме того, он ничем не выделялся на фоне многочисленных аналогов.
В выборку мы включили Angular 2, потому что он воспринимался как новая версия популярного AngularJS. На момент исследования он находился на стадии Release Candidate. Официальный выпуск произошел осенью 2016, к тому моменту мы в Mango уже вели на нем разработку. Собственно, «молодость» фреймворка была основным риском использования технологии. Но та стратегия развития, которую озвучивала компания Google, и вкладываемые ей ресурсы послужили поводом добавить Angular 2 в наше исследование.
Оценку фреймворков по критериям осуществляли по пятибалльной шкале на основе двух факторов: экспертное мнение разработчиков и архитекторов компании, работавших с несколькими из перечисленных технологий, и публичные исследования и официальные стратегии развития фреймворков.
Итоговый балл вышел следующий:
Технология | Средняя оценка с учетом веса критериев |
Angular 2 | 4,06 |
AngularJS | 4,00 |
React+Redux | 3,80 |
React+Backbone | 3,61 |
ExtJS | 3,57 |
Backbone | 2,27 |
В лидерах оказались Angular 2 и AngularJS, и выбор склонялся в пользу первого. Делать ставку на AngularJS было бы не прагматично: Angular 2 приходил ему на смену. Но все же мы явно выписали ключевые риски использования Angular:
Проект быстро закончит развиваться.
Проект будет долгое время нестабильным.
Не было готовых специалистов со знанием стандарта ES6 и языка TypeScript.
Не было хорошей документации.
Не было готовых сторонних компонентов.
Мы приняли эти риски. Angular стал в Mango основной технологией.
Второй этап оценки
Через год мы вернулись к оценке Angular. Хотелось еще раз свежим взглядом оценить, правильно ли был выбран вектор развития. Я вышел на исследование популярности web-технологий от аналитического агентства Developer Nation, выпущенное весной 2017.
Из данных исследования вытекало, что обеими версиями Angular в мире пользуется больше разработчиков, чем React: 21 % против 9 %. Это удивительно, так как по популярности в статьях и оценках на GitHub напрашивался противоположный вывод.
Также выяснилось, что Angular в большей мере предпочитают разработчики с опытом в Enterprise-технологиях, таких как Java или .NET. Это стало еще одним плюсом в пользу нашего выбора.
Внедрение: сложности и решения
Внедрение фреймворка мы начали в двух продуктовых командах. Они активно развивали новые сервисы, и использование новой технологии для них было проще всего. В главном web-проекте — личном кабинете Mango Office — перейти на новую технологию с наскока не получилось бы. В этом продукте внедрять Angular мы начали спустя несколько лет, после того как накопили опыт в других командах.
Личный кабинет Mango Office — это большое фулстек-приложение с бэкендом на PHP и фронтендом на jQuery. У него длинная история — больше 15 лет. Внедрить фронтенд технологии было непросто. Мы стали двигаться в двух направлениях: новые модули стали писать уже на Angular, а в текущем личном кабинете постепенно отказывались от jQuery в пользу React, тем более что пробное использование React уже было запущено. Мы переписывали виджеты с jQuery на React, что позволило постепенно улучшать интерфейс, не уходя надолго в рефакторинг кабинета.
Внедрению фронтенд-технологии сопутствовали изменения в бэкенде. Бэкенд также переписывался на микросервисы, в которые выносилась ключевая бизнес-логика. Фронтенд всегда шел за бэкендом. Перенос бизнес-бизнес логики — дело не быстрое, поэтому и перевод фронта на новую технологию шел не тем темпом, как хотелось бы.
Разумеется, в компании есть продукты, где внедрение такого крупного фреймворка, как Angular, было нецелесообразно. В первую очередь, к ним относятся виджеты, которые встраиваются на сайты клиентов и плагины для других систем (например, CRM). Там мы оставили использование более легковесных Vue и React, а в последствии частично перешли на чистый JavaScript.
Микрофронтенды
Данная тема заслуживает отдельной статьи, затрону ее здесь кратко. На определенном этапе мы пришли к тому, что разработку личного кабинета Mango Office должны вести разные продуктовые команды. На бэкенде благодаря микросервисной архитектуре разделение ответственности между командами произошло легко. На фронте пришлось внедрять микрофронтенды.
Архитектуру микрофронтендов построили на базе модуля Federation @angular-architects/module-federation. Большинство разделов начали встраивать как микрофронтенды. Бонусом такого подхода стало то, что мы смогли гладко встроить в единое приложение модули, написанные на React. Для этого оказалось достаточно завернуть React-приложение в Angular-обертку. Над разработкой модулей-микрофронтендов теперь могли работать разные команды.
Дизайн-система и библиотека компонентов
Внедрение единой технологии для фронтенда упростило внедрение корпоративной дизайн-системы в web-проекты. Разные команды годами пользовались разными библиотеками компонентов. Это усложняло пользовательский опыт и приводило к лишним трудозатратам по унификации UX/UI.
Пару лет назад мы приступили к разработке общей для всей компании библиотеки собственных компонентов в едином стиле Mango. На текущий момент вырос большой UI-kit на Angular и чуть поменьше на React. Этих библиотек хватает для разработки типового интерфейса в личном кабинете Mango Office.
В будущем, возможно, мы выложим наши наработки по дизайн-системе в открытый доступ.
Результаты
Подведем итоги за семь лет.
Большая часть фронтовых команд использует Angular. Треть продолжает писать на React, Vue и чистом JavaScript. Кому-то большой фреймворк не подходит, кому-то нужен чистый JS. Также остается один старый внутренний проект на ExtJS.
Риски, которые мы принимали, выбирая Angular, не сработали.
Разберем результаты:
Проект закончит развиваться. Технология развивается и поддерживается крупными вендорами. На нем написано уже столько кода, что в ближайшие годы окончание поддержки не предвидится.
Нехватка готовых специалистов. Специалистов со знанием Angular на рынке труда достаточно. Среднее время поиска меньше, чем для бэкендеров. Я считаю, это хороший показатель.
Слабое сообщество, документация, мало сторонних библиотек. Сообщество развито, много литературы, оригинальных решений, сторонних библиотек и пр. Конечно, для React всего этого в разы больше, зато для Angular качество в среднем выше.
Какие плюсы мы получили от использования единой технологии:
Angular оказался большим фреймворком, способным закрыть многие потребности команд. Использовать сторонние библиотеки и компоненты приходится редко.
Из первого пункта вытекает простота обновления версий базового фреймворка во всех проектах, что позволяет нам идти в ногу со временем. К использованию единой версии мы еще не пришли, но сделать это в будущем будет не трудно.
Сокращение трудозатрат и унификация интерфейсов за счет единой технологии и дизайн-системы.
Но не все надежды оправдали ожидания. Главный минус — распространение технологии в проектах идет не так быстро, как хотелось бы, и до сих пор не завершено. Причина — не в выбранной технологии, а в том, что переписывание многолетней кодовой базы не всегда целесообразно и рентабельно. Приходится, так сказать, есть слона по кускам.
Послесловие
Я постарался осветить опыт, который компания Mango Office накопила на пути внедрения единой технологии для фронтенда. Моей целью было продемонстрировать, что унификация влечет больше плюсов, чем минусов. Мы начинали с целого «зоопарка» устаревших технологий и пришли к желаемому единообразию. Выбор Angular себя полностью оправдал. Этот фреймворк достоин быть корпоративным стандартом.
Возможно у вас есть истории — успешные или не очень — о внедрении нового фреймворка. Расскажите в комментариях, будет интересно сравнить ваш и наш опыт.
Подписывайтесь на наши соцсети:
Аккаунты Mango Office
ВКонтакте: https://vk.com/mangotelecom
Телеграм: https://t.me/mango_office
