В Theodo с апреля 2018 года мы разрабатываем библиотеки общих компонентов React для одного из наших крупнейших клиентов. Мы доказали ценность поддержки такого проекта и стабилизировали его архитектуру и конфигурацию.
В этой статье мы хотим рассказать, что означает проект с разделяемыми компонентами и в какой ситуации стоит его реализовать.
Что такое проект общих компонентов?
Если вы разработчик, перейдите к следующему разделу.
Если нет, возможно, вы не знаете, что приложения состоят из двух источников кода:
- Пользовательский код
Бизнес-код, предназначенный для решения проблемы по-новому.
Примеры: веб-сайты Facebook или Airbnb, «Uber приложение" - Библиотеки
. Открытый или частный доступ и высоко факторизованный код, решающий общую проблему, призванную ускорить и усилить разработку нескольких приложений.
Примеры: React .JS framework , Система материального дизайна пользовательского интерфейса , Formik form manager
Тип библиотеки: общие компоненты / система проектирования
Среди этих библиотек часто можно найти библиотеки с предопределенными и адаптируемыми компонентами пользовательского интерфейса, которые помогают командам создавать пользовательский интерфейс намного быстрее и с большей согласованностью во всех приложениях.
Примеры: D3 , Bootstrap, Material UI (снова)
Стоит ли иметь свой?
При повторной разработке очень похожих компонентов несколько раз становится интересно разработать собственную библиотеку общих компонентов. Так и будет:
- экономия времени на разработку между командами - ›чтобы не разрабатывать одни и те же компоненты.
- помогает согласовать практики UX / UI с вашими приложениями - ›он централизует реализацию UX / UI и дизайн бренда в одном месте для всей вашей компании.
- принудительное согласование и обновление вашего технического стека в разных приложениях - ›поскольку будущие проекты с новейшими библиотеками должны быть совместимы с вашими общими компонентами.
- Упрощение обмена бизнес-правилами между командами - ›при совместном использовании компонентов в компании вы также можете совместно использовать бизнес-логику по сравнению с библиотеками с открытым исходным кодом
В последнее время мы видим все больше и больше компаний, начинающих подобные внутренние проекты. У каждого из них свой стек, особенности дизайна или даже бизнес-правила: они предпочитают свою систему. Один из последних в этой серии - Uber: https://eng.uber.com/introduction-base-web. Вы также можете взглянуть на Систему углеродного дизайна IBM.
Вот краткий обзор некоторых из наших общих компонентов:
Как я узнаю, что у моей команды должна быть библиотека общих компонентов?
Какие условия должны соблюдаться для поддержки такого проекта?
1. 🚀 Множество приложений
Состояние
- У вас параллельно работает несколько проектов и часто запускаются новые
- Общие компоненты становятся полезными, если есть возможность повторного использования как минимум 2 раза на компонент
Почему?
- Разработка такого проекта обходится дороже: поток разработки тяжелее, когда вы вносите вклад в библиотеки, качество и документация должны быть наивысшего качества, потому что они влияют на несколько продуктов и команд одновременно.
- В нашем собственном проекте мы внимательно следили за рентабельностью инвестиций и доказали, что совместное использование компонентов в два раза превышает затраты на их разработку.
2. 🏭 Один общий бизнес и дизайн
Состояние
- В большинстве ваших проектов используется один и тот же набор бизнес-правил и рекомендаций по дизайну.
- Со временем команды разработчиков воссоздают очень похожие функции
Почему?
- Если вы разделяете компоненты без состояния для создания дизайн-системы, ее главная ценность - унифицировать дизайн для всех приложений. Поэтому, если вы не соблюдаете это условие, вы теряете ценность совместного использования: компоненты станут слишком настраиваемыми, а значит, слишком сложными для разработки.
- Если вы хотите поделиться более крупными и связанными с бизнесом компонентами, это означает, что несколько приложений используют одни и те же бизнес-данные и правила.
3. ⚙️ Единый стек
Состояние
- Большинство ваших проектов используют один и тот же внешний фреймворк, например React или Vue.
- Технически общие компоненты должны иметь базовый стек, аналогичный их основным приложениям.
Почему?
- Простота совместного использования компонента полностью связана с библиотекой, используемой для его кодирования: встраивание Vue в React обходится дорого и часто может приводить к ошибкам / задержкам.
Возьмем пример:
Я работаю в ИТ-команде большого банка. Стоит ли начинать подобный проект в своей компании?
- 🚀 Множество приложений: в банке всегда есть как минимум 5 команд, работающих над разными приложениями параллельно ✅
- 🏭 Один общий бизнес и дизайн: все эти приложения используют одни и те же принципы UX / UI, и у них действительно одинаковые бизнес-данные и логика, на которых они основаны ✅
- ⚙️ Единый стек: команды выровняли свой стек, все они разрабатывают с использованием React, Redux и стилизованных компонентов ✅
🎉 Все зеленые, давайте начнем проект с общими компонентами!
Теперь, когда я убежден, с чего мне начать?
Чтобы помочь вам запустить или ускорить аналогичный проект, мы открыли исходный код всей нашей установки и документации. Там вы найдете наши самые ценные знания. У вас также есть возможность скопировать и вставить весь проект и повторно использовать его как есть.
Вы также можете найти дополнительные пояснения в видео и слайдах моего выступления на React Foo в марте.
Что дальше?
Мы продолжим улучшать и решать следующие задачи в рамках нашего собственного проекта «Общие компоненты». Мы планируем передать эти будущие знания через этот репозиторий с открытым исходным кодом, а затем углубиться в некоторые ключевые аспекты с дополнительными статьями.
Я надеюсь, что эта статья «принесла вам зерно на вашу мельницу», что она даст вам еще больше причин для начала чего-то подобного и поможет вам добиться успеха.
Не стесняйтесь присылать нам любые отзывы о форме и содержании, чтобы улучшить наши рекомендации и собственную реализацию!
Вы планировали сделать аналогичный проект? Или уже пробовали? А как у вас все прошло? Сообщите нам об этом в комментариях!
