Успешные практики разработки и управления общими компонентами между командами и проектами с Bit и друзьями.
Недавно я опубликовал Как мы действительно используем повторно используемые компоненты », где я поделился общими проблемами, которые узнали более 30 команд об общих компонентах.
В этом посте, основываясь на этих знаниях, я попытаюсь определить некоторые практики, которые помогут вашей команде успешно разрабатывать общие компоненты и управлять ими.
Мы кратко рассмотрим архитектуру, инструменты, дизайн, возможности обнаружения и совместную работу, чтобы преодолеть распространенные ошибки, с которыми неизбежно сталкивается большинство команд. Цель состоит не только в разработке общих компонентов; это для разработки общих компонентов, которые разные команды фактически будут использовать в своих разных проектах.
Следуя этим идеям, вы сократите время разработки, воспользуетесь модульностью для упрощения обслуживания, сохраните единообразие пользовательского интерфейса и упростите новым разработчикам возможность подключиться к системе и начать работу с ней.
Так что давайте продолжим и сразу приступим. Из-за раскрытия информации, этот пост в значительной степени относится к Bit. Это потому, что я считаю Bit часто лучшим инструментом и философией для работы. Я активно работаю над Bit, что может вызвать у меня предвзятость. Это нормально. Есть много отличных инструментов, таких как Lerna, Storybook и другие, которые тоже полезны для этого.
Работая над Bit, я так хорошо познакомился с этим вариантом использования, и с этим пониманием он был создан именно для этой цели. Если вы не хотите использовать Bit, просто игнорируйте его. Вы все еще можете многому научиться, изучив, как можно описать различные варианты использования, и лучше понять, как достичь своих целей.
Не стесняйтесь комментировать, спрашивать или добавлять что-либо и делиться своим опытом.
Разберитесь в своей архитектуре и потребностях
Прежде чем делать что-либо еще, вы должны действительно понимать свои потребности. Это означает понимание как человеческой архитектуры, так и архитектуры кода для компонентов.
Большинство команд доходят до того, что у них уже есть набор компонентов, которые можно использовать повторно, и они пытаются придумать, как ими поделиться.
90% случаев использования, которые я видел, попадают в одну из четырех категорий:
а) Одна команда с одним приложением - где вы пытаетесь создать систему проектирования многократно используемых компонентов и повысить модульность приложения.
б) Одна команда с более чем одним приложением - если вы хотите использовать общие компоненты между двумя или более приложениями.
c) Две команды с двумя или более приложениями - если вы хотите использовать компоненты для большего числа людей и приложений.
г) Инфраструктурная команда с множеством групп-потребителей и приложений - там, где вам нужна стандартизованная масштабируемая архитектура для совместного использования компонентов, поскольку одна команда публикует компоненты, а многие команды / приложения их используют.
Попали в одну из вышеперечисленных категорий? Отлично. Если нет, не стесняйтесь оставлять комментарии ниже, и я сделаю все возможное, чтобы помочь. Давайте углубимся в каждую категорию.
а) Одна команда - одно приложение
Итак, ваша команда создает приложение. Зачем, черт возьми, вам нужны общие компоненты? где вы ими поделитесь? а с кем? Внутренне это было нашим вариантом использования некоторое время. Наконец, нас осенило: нам действительно нужны модульные компоненты.
Почему? Потому что это значительно упрощает добавление новых функций. Это упрощает рефакторинг и поддержку. Это сокращает время обучения новых разработчиков. Он превращает наши компоненты в дизайн-систему нашего приложения. Он обеспечивает постепенный рефакторинг и упрощает создание нового следующего приложения при необходимости. Это также упрощает обмен кодом между передней и задней частями приложения.
Как это выглядит:
Таким образом, для этого более простого рабочего процесса, который обычно используется в небольших стартапах и независимых командах, меньше смысла в управлении и синхронизации компонентов в проектах - и больше в рабочем процессе вокруг приложения.
Ваши компоненты обычно являются внутренними по отношению к приложению и разрабатываются в рамках проекта. Обычно они даже не публикуются в виде пакетов.
Вы работаете с Figma / Sketch / другими инструментами дизайна для разработки компонентов, возможно, используя Zeplin между ними, а затем просто разрабатываете их в приложении.
Рекомендуемый рабочий процесс:
В создании библиотеки особого смысла нет - где вы будете ее использовать? Вместо этого вы хотите превратить свои компоненты в реальную систему проектирования, чтобы вы могли легко узнать, какие компоненты доступны, увидеть их дизайн и использовать их.
Я бы рекомендовал оставить компоненты в приложении, используя Bit, чтобы изолировать их и объединить их в коллекцию многократного использования.
Пример репозитория приложения:
Пример коллекции компонентов:
Что вы получите:
- Создание новых функций или создание нового приложения - это просто работа с конструктором Lego. Вы постепенно реорганизуете свое приложение, сделав его более модульным, что приведет к тому, что приложение будет разрабатываться гораздо быстрее, а кодовая база станет лучше и удобнее в обслуживании.
- Отсутствие рефакторинга для совместного использования компонентов - Bit автоматически изолирует компоненты, чтобы вы могли экспортировать и повторно использовать их. Никаких изменений кода.
- Система визуального дизайна, состоящая из реальных компонентов. Вы можете увидеть, как выглядят компоненты, поиграть с ними на игровой площадке и многое другое.
- Постепенный рефакторинг. Хотите начать использовать TS в своем JS-приложении? Нет проблем - вы можете постепенно реорганизовать компоненты в одном репо. да.
- Автоматическое управление зависимостями для ваших компонентов - Bit автоматически определяет и обновляет (по запросу) все зависимости для компонентов в репозитории, что значительно упрощает и ускоряет разработку. Изменили стиль компонента и обновили его версию? Запустите
bit status, и Bit позволит вам обновить все зависимые компоненты до новой версии. - Пониженная кривая обучения. Новый разработчик может легко приступить к работе и узнать, какие компоненты доступны и как их использовать.
- Лучшее покрытие тестами - Bit будет запускать модульные тесты для каждого компонента, поэтому у вас будет очень наглядная и грубая проверка статуса вашего TDD или его отсутствия.
б) Одна команда - два приложения
Итак, в этом сценарии у вас есть одна команда, работающая над двумя или более проектами. Классические варианты использования - это веб-приложение и мобильное приложение, backEnd и frontEnd или просто создание нескольких приложений для разных целей и костюмов.
Как это выглядит:
Этот сценарий обычно возникает, когда начинаются настоящие вопросы. С одной стороны, создание общей библиотеки на данном этапе может оказаться серьезным излишеством. С другой стороны, альтернативы могут не привести к реальному объему необходимого совместного использования кода.
Обычно вы начинаете видеть дублированный код между проектами. Сначала служебные функции, возможно, некоторые функции промежуточного программного обеспечения и, наконец, целые компоненты.
Некоторые люди будут настаивать на библиотеке, но это уже перебор. Некоторые могут даже опубликовать один или два небольших пакета, которые они отделили от репозиториев. Вы начнете говорить о монорепозитории или мультипакетном репо с Lerna и т. Д.
Рекомендуемый рабочий процесс:
Библиотека - это долгосрочное обязательство, требующее серьезных ресурсов для создания и поддержки и создает конфликты, когда у двух проектов разные потребности.
На этом этапе вы хотите сохранить исходный код общих компонентов в проектах, но упростить повторное использование и синхронизацию компонентов. В противном случае у вас неизбежно будет расти копипастинг, и ваш долг будет расти.
Вы можете использовать Lerna для рефакторинга проектов в проекты с несколькими пакетами и публикации некоторых основных пакетов в NPM. Однако накладные расходы, связанные с этим рабочим процессом, не будут работать для многих более мелких компонентов. Проекту, использующему пакеты, будет сложно их изменить, поскольку их исходный код находится в другом проекте и в первую очередь служит этой цели.
Используя Bit, вы можете изолировать существующие компоненты из одного проекта и повторно использовать их в другом. Затем вы можете использовать его для разработки одних и тех же компонентов из двух разных репозиториев одновременно, поскольку версии изменений могут быть либо обновлены в обоих проектах, либо совместно использованы как отдельные компоненты.
Что вы получите:
- Мгновенно обменивайтесь общим кодом между проектами - используйте изоляцию компонентов Bit, чтобы быстро обмениваться существующим кодом и держать его под контролем.
- Разработайте один и тот же код из двух проектов - Bit позволяет перенести общий компонент в другой проект и продолжить его там.
- Синхронизация и объединение изменений - Bit позволит вам при необходимости обновлять изменения между проектами и даже расширять Git для объединения изменений между ними. Если нет, то тоже ничего - просто поделитесь изменениями как новым компонентом.
- Все преимущества раздела А выше.
в) Две команды по две заявки
Итак, здесь открывается совершенно новое измерение. Нам нужно не только делить код между нашими приложениями, но и между разными людьми.
Это означает, что в дополнение к рабочему процессу совместного использования кода нам необходимо создать рабочий процесс, в котором люди могут практически обнаруживать ваши общие компоненты и совместно работать над ними .
Как это выглядит:
На данный момент у вас есть две команды, работающие над несколькими разными проектами. Одна команда находится в Нью-Йорке, а другая - в Лондоне. Каждая команда создавала свои собственные компоненты, и теперь вы поняли, что они должны стандартизировать.
Затем вы начинаете думать - почему бы не поделиться и не использовать повторно?
Итак, вы начинаете создавать библиотеку для них обоих. Одна из команд создает библиотеку, в идеале, сотрудничая с другой командой. Обычно нет.
Затем начинают возникать проблемы. Обе команды используют React, но одна также использует TS и тестирует компоненты с другим фреймворком. Вы начинаете обсуждать стандартизацию. Дизайн определяется командой дизайнеров, но все же разные приложения имеют несколько разные потребности - от полей до всего остального.
Затем вы понимаете, что вам нужно публиковать каждый компонент индивидуально, и начинаете думать о Bit и Lerna. Вы также понимаете, что вам необходимо создать портал обнаружения компонентов, например StoryBook или сайт документации.
Рекомендуемый рабочий процесс:
Итак, в основном мы хотим иметь универсальный центр, где обе команды могут легко обмениваться, обнаруживать, использовать и изменять компоненты по мере необходимости.
Вы можете создать одну коллекцию Bit для двух команд или две коллекции - по одной для каждой команды. Тебе решать. Если у вас есть библиотека (вероятно, она у вас есть), просто поделитесь компонентами из библиотеки с коллекцией.
Когда у вас есть коллекция, она работает как единый центр, где обе команды могут легко обмениваться компонентами, обнаруживать общие компоненты, устанавливать компоненты по мере необходимости, предлагать обновления и изменения из обоих проектов и оставаться в синхронизации.
Вот пример из популярной библиотеки semantic-ui-react:
Что вы получите:
- Универсальный центр, где обе команды могут легко обмениваться компонентами
- Обнаружение общих компонентов - поиск в коллекциях, визуальный просмотр компонентов, игра с ними в Интернете, просмотр автоматически созданных справочных документов по API и многое другое.
- Каждая команда может изменять компоненты, совместно используемые другой командой, прямо из своего собственного проекта. Другая команда поделилась отличным компонентом кнопки, но поля неправильные? просто
bit importкод и модифицируйте его. Понравились изменения, достаточные для их повторного использования? поделитесь обновлением обратно. - Стандартизация дизайна и технологий.
г) Инфраструктурная команда с несколькими группами-потребителями и приложениями
По мере роста вашей организации общие компоненты становятся стратегической проблемой, выходящей за рамки экономии времени или создания более модульного программного обеспечения, и становится критически важным требованием в стандартизации технологий и UI / UX.
Как это выглядит:
Организация обычно назначает одну команду для создания, обслуживания и распространения компонентов. Эту команду часто называют «командой frontEnd Infra».
Эта команда получает дизайн-систему от дизайнеров и реализует общую библиотеку пользовательского интерфейса с набором компонентов. Примеры: Gestalt от Pinterest, Grommet от HP, Polaris от Shopify и многие другие.
Затем начинается борьба за истинную возможность повторного использования. По сути, это означает, что инфракрасной команде нужно каким-то образом заставить все остальные команды использовать эти компоненты.
Это непростая задача, поскольку другие команды опасаются связывать свои приложения с разработкой библиотеки третьей части с готовыми компонентами. Что происходит, когда группе-потребителю нужно внести изменения в компонент? может быть, отрегулировать поля? Придется пиарить библиотеку и ждать ...
Другой проблемой является обнаруживаемость компонентов, что часто приводит к чрезмерно сложным сайтам с документами и вики, которые людям нужно читать и просматривать, когда им действительно нужна просто кнопка и несколько примеров API.
В результате такие библиотеки, как правило, получают меньшее распространение, чем хотелось бы, и процесс их принятия становится долгим и утомительным для команды разработчиков инфраструктуры.
Рекомендуемый рабочий процесс:
Вот то, что нам нужно достичь, чтобы добиться реального внедрения общих компонентов между «публикующей» и «потребляющей» группами:
- Обнаружение общих компонентов
- Умение быстро понимать и использовать компоненты
- Возможность вносить изменения при необходимости со стороны потребителя
Обычно можно выбрать один из двух вариантов:
а) Библиотека пользовательского интерфейса + бит
б) UI Library + Lerna + NPM + StoryBook
Давайте рассмотрим.
Библиотека пользовательского интерфейса + бит
В этом рабочем процессе вы будете использовать Bit для управления и совместного использования компонентов из вашей библиотеки. Что вы получите и почему:
- Портал мгновенного обнаружения в виде общих коллекций. Например, вот анимация React, библиотека пользовательского интерфейса от лаборатории Formidable и подборка компонентов с Bit.
- Каждый компонент будет автоматически представлен с примером игровой площадки, автоматически извлеченной ссылкой на API и результатами сборки + тестирования. Дизайнеры также могут сотрудничать на этом визуализированном портале.
- Индивидуальное потребление компонентов прямо из общего портала без рефакторинга библиотеки (с использованием Lerna / других инструментов).
- Двустороннее сотрудничество для компонентов, когда каждый потребитель-разработчик может установить компоненты с помощью NPM / Yarn, но также использовать Bit для импорта и изменения компонентов прямо из своих проектов и совместного использования новой версии. Это помогает значительно увеличить распространение общих компонентов.
- Более простая разработка компонентов в библиотеке, поскольку Bit автоматически обрабатывает и позволяет обновлять как изменения исходного кода, так и зависимости.
- Меньше инструментов в вашей цепочке инструментов.
- Новые возможности: например, вы можете отделить логику от стиля. Вы можете поделиться 30 компонентами пользовательского интерфейса React и 10 компонентами тематики, которые разработчики могут составить для добавления стиля к компонентам по мере необходимости.
- Постепенный рефакторинг и модульность компонентов в вашей кодовой базе.
Библиотека пользовательского интерфейса + Lerna + NPM + StoryBook
В этом рабочем процессе вы будете использовать Lerna для преобразования вашей библиотеки в репозиторий с несколькими пакетами и публикации каждого из них в NPM. Сверху вы создадите сайт документации для библиотеки и, возможно, добавите StoryBook поверх для быстрого прототипирования.
Что вы получите:
- Реорганизованное репозиторий с несколькими пакетами с Lerna, из которого отдельные компоненты могут быть опубликованы в NPM.
- Портал Wiki для компонентов с примерами / справочником API по вашему выбору, с дополнительными функциями по выбору.
- Быстрое прототипирование компонентов с помощью StoryBook и его друзей.
В конечном итоге вы также можете комбинировать все эти инструменты с Bit - при условии, что вы можете создавать, публиковать и внедрять общие компоненты. Тебе решать.
Заключение
Важно помнить, что модульное совместное использование кода не просто поддерживает стандартизацию (которая должна быть достигнута, а не принудительно), а скорее способствует более быстрому созданию лучшего программного обеспечения за счет модульности, повторного использования кода и разделения задач. Это помогает развивать TDD, упрощает обслуживание и помогает привлекать новых разработчиков и новые команды к разработке ваших приложений.
При попытке совместного использования компонентов пользовательского интерфейса необходимо устранить разрыв между дизайном, разработкой, использованием и совместной работой над компонентами. Этот процесс начинается с истинного понимания ваших потребностей, определения ваших целей и ограничений (как человеческих, так и технологических), выбора наиболее подходящих инструментов для работы и работы над достижением истинной возможности повторного использования общих компонентов.
Если все сделано правильно, вы не просто делитесь компонентами. Вы создаете систему проектирования, построенную из компонентов, ускоряете разработку, обеспечиваете единообразие взаимодействия и ищите своих пользователей во всех приложениях и создаете более совершенное модульное программное обеспечение.
