Привет! Меня зовут Даниил Пацкин. Уже около семи лет я занимаюсь фронтенд-разработкой, из которых два года — в QIC digital hub, руковожу командой, отвечающей за фронтенд продуктовой части и дизайн-системы.
За это время я убедился: удовольствие от работы напрямую зависит от того, насколько грамотно выстроены процессы в команде. В этой статье я расскажу о Storybook — инструменте, который помогает экономить время и повышать качество кода.
Проблемы разработчика: бизнес vs инженерные задачи
Работа фронтенд-разработчика состоит из двух типов задач:
Бизнес-задачи — имеют четкую область выполнения и понятную пользу для бизнеса
Инженерные задачи — более абстрактные, и часто приходится объяснять, зачем бизнесу код, который «уже написан»
От того, как сочетаются эти два направления, зависит многое: можно либо выгореть, либо получать настоящее удовольствие от работы.
Как устроен процесс в QIC digital hub
В нашей команде, которая занимается страхованием путешественников, процесс выглядит так:
Бизнес формирует требования
Продукт-менеджер передаёт их дизайнерам и UX-райтерам
Аналитик фиксирует всё в Confluence
Команда разработки оценивает задачи на PBR (Planning Backlog Refinement), декомпозирует и приступает к реализации
Готовый код проходит QA, тестируется, релизится, запускаются автоматические тесты
При этом бизнес всегда стремится получить максимум business value при минимальном time to market. Мы, как разработчики, можем влиять лишь на два этапа — декомпозицию и разработку.
Главный вывод, к которому я пришёл: внимание разработчика — ограниченный ресурс, и его нужно беречь. Процессы должны быть выстроены так, чтобы программист сосредотачивался на сути задачи, а не на отвлекающих мелочах. И здесь на помощь приходит Storybook.
Что такое Storybook
Storybook — это инструмент для создания и ведения «витрины» компонентов с описанием их состояний. Каждый компонент описывается отдельной сторей (story). Например, компонент Checkbox может иметь сторис: default, disabled, error и т. д. Фактически каждая сторя — это наглядный тест-кейс, вроде Checkbox state: default.
Как работает Storybook: витрина, тестирование и документация
1. Витрина компонентов
Storybook визуализирует все состояния компонентов через стори (stories). Например:
Компонент Checkbox может иметь стори для состояний: default, disabled, with error и других
Каждая сторя — это по сути визуализированный тест-кейс, показывающий компонент в конкретном состоянии
В коде сторя представляет собой набор пропсов, передаваемых в компонент
2. Интегрированное тестирование
Storybook меняет подход к тестированию компонентов.
Базовое тестирование:
Написание стори = создание теста
Компонент рендерится с заданными пропсами, что уже проверяет его корректность
Интерактивное тестирование:
Для состояний, требующих пользовательских действий (например, ввод в поисковое поле), используются play-функции
Play-функции автоматически эмулируют взаимодействие пользователя
По сути это unit-тесты, но с визуальным представлением
Screenshot-тестирование через Chromatic:
Автоматически обнаруживает визуальные изменения в компонентах
Позволяет сравнивать скриншоты между версиями
Особенно полезно для крупных проектов (например, 28 компонентов → 200 сторей)
Выявляет даже незаметные глазу изменения (например, перестановку иконок)
3. Автоматическая документация
Storybook генерирует документацию на лету:
На основе TypeScript-типов создаёт интерактивные элементы управления (радиокнопки, селекторы)
Отображает все пропсы и их значения по умолчанию
Поддерживает JSDoc для добавления подробных описаний
Документация всегда актуальна, так как синхронизирована с кодом
Как это работает вместе
Процесс выглядит просто и логично:
Разработчик создает компонент
Добавляет сторис для всех его состояний
При необходимости — прописывает play-функции
Затем Storybook автоматически:
создаёт визуальную витрину компонентов,
генерирует тесты
формирует документацию
а Chromatic отслеживает визуальные изменения
Такой подход даёт сразу несколько преимуществ:
наглядность всех состояний компонента
автоматическое тестирование
актуальную документацию
быстрое обнаружение визуальных регрессий
В итоге команда получает систему, которая одновременно ускоряет и повышает качество разработки UI-компонентов.
Создание всего одной стори в Storybook даёт нам сразу несколько преимуществ:
Готовые unit-тесты через проверку рендеринга компонента.
Автоматические screenshot-тесты для визуального контроля.
Полноценную документацию компонента.
Возможность подключения дополнительных проверок: snapshot-тестов и accessibility-тестов.
При наличии в проекте TypeScript, линтеров и форматеров мы получаем:
Компонент, прошедший все этапы автоматизированной проверки.
Гарантированное соответствие код-стайлу и типам.
Уверенность в качестве выполненной задачи.
Когда все проверки проходят успешно, разработчик может быть уверен: компонент реализован корректно, стабильно и поддерживаемо.
Плюсы и минусы Storybook
Как и любой инструмент, Storybook не лишён сложностей. Главная из них — стартовая настройка. Особенно если проект построен не на React, а, например, на Vue.js. Storybook изначально разрабатывался под React, поэтому с ним работает «из коробки», а с другими фреймворками потребуется больше времени на конфигурацию.
Но добавить Storybook в проект — это только половина дела. Важно выработать культуру работы с ним. Следует придерживаться принципа «Storybook first» и назначить человека, который будет следить за качеством сторей — чтобы их создавали осмысленно, а не «для галочки». Цель внедрения Storybook — упростить работу, а не добавить лишний процесс.
Ещё один нюанс — интеграция с другими инструментами. Если у вас в проекте используются редкие или кастомные решения, могут возникнуть сложности с их подключением.
Однако все эти усилия окупаются. В результате команда получает единое пространство для работы с компонентами: разработчик, открывая Storybook, сразу видит, какие компоненты нужно создать или изменить. Всё прозрачно: он добавляет новые сторис или редактирует существующие — и из них быстро собирается готовый экран.
## Итоги
Storybook уже включает в себя всё необходимое для тестирования и автоматических проверок. Это значит, что качество кода растёт, а необходимость в рефакторинге сокращается. В итоге у нас остаётся больше времени на решение бизнес-задач.
Да, на старте внедрение Storybook может немного замедлить процесс. Бизнес хочет быстрых результатов (больше value, меньше time to market), а мы добавляем новые инструменты, что кажется шагом назад. Но когда процесс налажен, всё начинает работать на нас — автоматизация сокращает время тестирования, снижает нагрузку на QA, и в итоге более качественный продукт быстрее попадает в продакшн.