Если вы читаете это как фронтенд-инженер, я уверен, что вы использовали Сборник историй в том или ином качестве на протяжении своей карьеры, но считаете ли вы Сборник историй необходимым? Большинство разработчиков, с которыми я работал, рассматривают это как еще одну раздражающую зависимость от обновлений (наряду с проклятыми модулями и тестами e2e + другими хлопотами по разработке). Тем не менее, я бы решительно заявил, что это важно при преобразовании устаревших веб-продуктов в современный стек. Я бы сделал еще один шаг, чтобы утверждать, что это должно быть параллельно любой технологической сборке.

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

Что такое сборник рассказов?

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

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

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

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

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

Как правильно использовать Storybook?

Мы все слышали поговорку Есть много способов содрать шкуру с кота или Есть «101 способ решить любую проблему», и то же самое можно сказать об использовании сборника рассказов в проекте, так что же представляет собой правильный способ? его использования?

Как и в большинстве случаев в разработке, не существует единого «правильного» способа использования Storybook, но подавляющее большинство разработчиков согласны со следующими основополагающими идеями:

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

Эти фонды могут также распространяться на:

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

Вы, вероятно, можете подвести итог из статьи до сих пор; Я считаю, что вышеупомянутые расширения должны быть основополагающими для любого процесса разработки, но, как я упоминал в предыдущем сегменте без дальнейшего расширения, Storybook становится (хотя и) очень обширной средой песочницы. Итак, каковы следующие шаги, чтобы сделать этот инструмент более универсальным и, следовательно, приблизить нас к тому, что, по моему мнению, должно быть правильным использованием? Интеграция сборника рассказов.

Интеграция со сборником рассказов

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

Вот несколько примеров интеграции Storybook:

  • Дополнения: это встроенные плагины Storybook, которые предоставляют дополнительные функции, такие как проверка доступности, создание документации и редактирование реквизитов компонентов в реальном времени.
  • Пользовательские темы: Storybook позволяет пользователям создавать и использовать собственные темы, соответствующие их бренду или системе дизайна. Доступны плагины для упрощения создания пользовательских тем и управления ими.
  • Плагины для интеграции. Эти плагины обеспечивают интеграцию с другими инструментами, такими как GitHub, Figma или системами дизайна. Они могут автоматически импортировать компоненты или файлы дизайна в Storybook и синхронизировать их.
  • Подключаемые модули аналитики. Эти подключаемые модули позволяют пользователям отслеживать поведение пользователей и использование компонентов в Storybook, предоставляя информацию, которая может помочь в будущих решениях по разработке.

Каково мое определение «правильного» использования сборника рассказов?

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

Теперь некоторые из вас могут подумать, что это анти-agile и фактически добавляет слишком много препятствий к доставке продукта. Действительно, некоторые продакт-менеджеры, читающие это, могут увидеть в этом еще одну причину, по которой ваши команды будут придумывать оправдания доставки, что еще больше задержит выполнение спринта. Я, однако, полностью не согласен, и я скажу вам, почему.

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

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

И так далее.

Но почему это важно? Что такое «правильное» использование сборника рассказов? Я слышу, как ты плачешь. Давайте углубимся в это теперь, когда я подготовил сцену.

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

  • Взаимодействия — это расширение, которое оживляет ваши модульные тесты. Вы можете визуализировать каждый тест прямо перед собой и убедиться, что он проверяет предполагаемую функциональность.
  • Accessibility — это расширение, которое буквально говорит вам, что является и что не проходит по доступности. Таким образом, вы можете вносить коррективы в реальном времени, чтобы убедиться, что каждый компонент проходит проверку. Он также предоставляет вам инструменты специальных возможностей, которые позволяют вам визуально просматривать компоненты так, как это сделал бы человек с нарушениями зрения, чтобы вы могли дополнительно проверить свою работу.
  • Интеграция JIRA встраивает тикет или тикеты, относящиеся к каждому компоненту. Это позволяет вам иметь буквально контрольный список целей вашего билета в браузере, что позволяет вам убедиться, что вы достигли каждой цели.
  • Designs — это расширение, позволяющее просматривать ваш компонент прямо из дизайнерского документа Figma. Это позволяет любому человеку сравнить ваш компонент с проектным документом и, следовательно, позволяет вам убедиться, что вы все сделали правильно. Существуют также другие интеграции для XD, Sketch и т. д.
  • Viewports — это расширение, которое позволяет вам добавлять пользовательские размеры области просмотра для нескольких размеров мобильных устройств, планшетов или настольных компьютеров. Это особенно полезно для обеспечения полной отзывчивости вашего компонента без необходимости использовать внешнее программное обеспечение или полагаться на инструменты браузера Chrome.
  • Responsive Columns — это расширение, которое позволяет вам настроить область просмотра в соответствии с вашей системой интервалов в проектных документах для вашей веб-страницы.
  • Measure — это расширение, которое идеально подходит для обеспечения идеального соответствия ваших проектов проектному документу с точностью до пикселя.

Некоторые почетные упоминания включают:

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

В Storybook, конечно же, встроены Документы, которые вы можете использовать для документирования (я знаю, да) вашего компонента по мере его создания (отлично работает с Typescript), и Аргументы, которые позволяют вам настроить макет/макеты по умолчанию и поэтому живите, чтобы редактировать компонент в режиме реального времени.

Вы можете визуализировать, как они оба работают с официальной книгой историй Adobe: https://opensource.adobe.com/spectrum-web-components/storybook/?path=/story/accordion--default

Аргументами можно управлять в системе подменю «Элементы управления» под окном компонента, и вы можете переключиться на «Документы» в меню заголовка выше (по умолчанию вы можете «Холст»).

Являются ли Storybook необходимыми для преобразования устаревшего продукта в современный стек технологий?

Теперь, когда у вас есть представление о том, что такое Storybook, а я внушил вам свое мнение, давайте вернемся к сути статьи: Является ли Storybook необходимым при переходе от устаревшей веб-технологии к современному стеку?

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

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

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

  • Проверка формы.
  • Государственное управление.
  • Обработка и проверка файлов cookie.
  • Серверный или другой сервисный запрос для проверки входа.
  • Обработка ошибок.
  • Отзывчивый дизайн.
  • Обработка запросов.

и так далее.

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

Именно здесь на помощь приходит сборник рассказов, который на самом деле помогает заинтересованным сторонам понять огромный объем работы, выполняемой на каждой странице/компоненте, например:

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

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

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

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

Как я упоминал ранее, использование сборника рассказов для URL-адреса действительно помогло нашим отношениям с клиентом. Я не упомянул, что на самом деле это была трансформация платформы электронной коммерции, созданной в 2001 году.

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

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

Я большой сторонник Storybook в целом, но я не могу достаточно передать, как наличие клиента, работающего с вами в окопах, помогло как в определении целей доставки продукта, так и в командном духе (с обеих сторон).

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

В заключение, должен ли Storybook иметь важное значение для трансформации наследия в современную веб-разработку? Да, без сомнения.

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