Как создавать компонуемое программное обеспечение, которое позволяет командам работать автономно и независимо выпускать новые функции.

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

Система дизайна в распределенном программном обеспечении поддерживается как независимые компоненты, размещенные в области «дизайна» и принадлежащие команде разработчиков.

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

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

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

Что такое область действия и как она работает?

Прежде чем мы углубимся в конкретные области, давайте на минутку поймем, что такое «область действия» в контексте Bit.

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

Например, чтобы поддерживать компонент кнопка-переключатель, вы должны сначала импортировать его из удаленной области видимости в локальную рабочую область:

bit import showoff.design/inputs/toggle-button

После того, как вы внесли свои изменения, вы должны создать новую версию и экспортировать ее обратно в удаленную область:

bit snap showoff.design/inputs/toggle-button && bit export

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

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

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

Область разработки: многоразовые среды разработки

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

Чтобы проиллюстрировать это, давайте посмотрим на среду разработки компонента реагировать с mui (env). Эта среда предоставляет компонентам необходимые инструменты и конвейер сборки. Он также создает предварительные просмотры компонентов, по умолчанию завернутые в организационную систему проектирования на основе MUI.

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

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

Имейте в виду, что эта настройка не ограничивается React или даже фронтенд-разработкой. Область разработки часто также предоставляет среды разработки компонентов для серверных компонентов, таких как модули NodeJS, рабочие процессы Cloudflare, лямбда-выражения AWS и т. д.

Область проектирования: объединение стандартных блоков

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

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

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

Сфера действия "Свяжитесь со мной": стандартизированные функции

Далее идет область свяжись со мной, прекрасный пример области функции. Эта область содержит компоненты, связанные с контактной функцией наших проектов, такие как обработчик контактной формы (лямбда-функция AWS) и контактная форма (компонент React).

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

Структурируя организацию таким образом, мы получаем множество преимуществ. Например, рассмотрим случай области «auth». Если бы каждому подразделению пришлось поддерживать свою собственную команду «авторизации», это привело бы к значительному дублированию усилий.

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

Если команда или разработчик обнаружат, что им необходимо расширить API (контактную форму), рекомендуемым подходом будет предложить изменения группе «Свяжитесь со мной». Затем они могут оценить, широко ли применима запрошенная функциональность, и включить ее в основной компонент контактной формы. Таким образом, вся организация получает выгоду от этого усовершенствования.

Область для начинающих: катализатор развития

Область «стартеры» действует как катализатор для разработчиков, выступая в качестве репозитория для шаблонов рабочей области. Эти шаблоны могут служить двум основным целям: облегчение обучения и ускорение развития.

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

Для ускорения разработки «стартовые» шаблоны полезны при работе над большим приложением. Помните, что в Bit нет такого понятия, как клонирование всего репо — вы импортируете только то, над чем работаете, в свое рабочее пространство.

Таким образом, вместо того, чтобы импортировать все приложение и все связанные компоненты каждый раз, когда вы работаете, вы создаете «стартер», который импортирует приложение и необходимые компоненты. Это позволяет разработчикам быстро начать работу над своими конкретными задачами, не увязая в процессе настройки.

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

Рассмотрим пример нашего стартера bit.dev для нашего сайта сообщества. Он импортирует приложение и маршруты документации, позволяя разработчикам быстро импортировать и редактировать определенные компоненты MDX, необходимые для внесения изменений. Все дело в упрощении и ускорении процесса разработки.

Область личного портфолио: готовый продукт

Объем «личного портфолио» воплощает в себе объем продукта, в котором живет конечный продукт. Эта область представляет собой законченное приложение, готовое к развертыванию.

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

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

Давайте совершим краткий обзор приложения «личное портфолио»:

  1. Целевая страница: это целевая страница портфолио, где пользователи получают первое впечатление о владельце портфолио. Он включает в себя основные детали и краткое введение.
  2. Страница проектов: на этой странице отображаются проекты владельца портфолио с описаниями, используемыми технологиями и ссылками на живые демонстрации или репозитории кода.
  3. Контактная страница: здесь пользователи могут связаться с владельцем портфолио. Здесь используется компонент контактной формы из нашей области свяжитесь со мной, что иллюстрирует возможность повторного использования компонентов в разных областях.
  4. О странице: эта страница дает более глубокое представление о прошлом, навыках и опыте владельца портфолио. Это рассказ о профессиональном пути владельца портфеля.

Как видите, каждую страницу приложения «личное портфолио» можно разветвить, изменить и развернуть как независимую сущность, сохраняя при этом согласованность и стандартизацию всего портфолио.

Заключение

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

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

Итак, на этом мы завершаем наше исследование возможностей организации с помощью Bit. Следите за нашей следующей публикацией, в которой мы углубимся в динамику управления этими областями и их взаимодействием. Это увлекательная тема, которую вы не захотите пропустить!