Storybook でサクサクコンポーネント開発

suzuki

こんにちは、Gaji-Labo 鈴木です。
今回はフロントエンド開発時に使っている、コンポーネントを開発するためのオープンソースツール Storybook をご紹介します。

Storybook の良いところ

機能実装とは分離された場所にコンポーネントをのせていくことで、スムーズに開発ができ、プロジェクトを前進させるのに有効なツールだと感じています。
実際にどんなところが良いのかを以下に解説していきます。

作りやすい

Gaji-Labo では開発時にコンポーネント単位でタスクを進めるようにしています。
最小単位のコンポーネントが切られているので、その粒度でコンポーネントを作ることができます。
コンポーネントを実装して Storybook に追加するまでを1タスクとすると、作業分担もしやすく他のメンバーと並行しての作業もスムーズです。

レビューされやすい

Storybook 駆動開発の場合、基本的に1コンポーネント1 PullRequest になることが多いです。
作業内容を表すと、以下のような流れになります。

  • コンポーネントの実装
  • コンポーネントのスタイリング
  • Storybook へのコンポーネント追加
  • テストの追加

このような作業内容だとレビュアーはコンポーネントが期待通り実装されているかにフォーカスしてレビューすることができます。
また、 Storybook を起動すれば実際にコンポーネントの動作を確認することもできます。
このような理由により、レビュアーへの負担が少なくレビューされやすい状態を整えることができると感じています。

マージされやすい

前述のとおり、Storybook 駆動開発では1コンポーネント1 PullRequest でレビューがされやすくなります。
そして、実装したコンポーネントは Storybook への追加のみで、機能実装への組み込みはありません。
マージすることでの影響範囲が狭く、結果として PullRequest がマージされやすくなります。

このように、開発・レビュー・マージのサイクルを小さく速く回すことで、スムーズな開発に繋がっていると思います。

まとめ

一見遠回りに感じる Storybook での開発ですが、実際にこのフローに沿って開発をしていると、それぞれの作業がサクサクすすむことで結果的に高速な開発に繋がっていると感じています。

他にも開発フローに Storybook を採用していてこんな良い使い方もあったよ、などありましたらぜひ教えてください!

開発のお悩み、フロントエンドから解決しませんか?

あなたのチームのお悩みはなんですか? 「腕の良いエンジニアに重要でない作業まで任せてしまっている」「腕の良いデザイナーに主業務以外も任せてしまっている」「すべての手が足りず細かいことまで手が回らない」などなど… 。

そんなときは、相談相手としてGaji-Laboにお気軽にお声がけください。あなたの開発チームに足りていない役割や領域を適切に捉えてカバーすることで、チーム全体の生産性と品質をアップさせるお手伝いをします。

オンラインでのヒアリングとフルリモートでのプロセス支援に対応していますので、リモートワーク対応可のパートナーをお探しの場合もぜひ弊社にお問い合わせください!

お悩み相談はこちらから!


suzuki

投稿者 suzuki

HTML/CSS のマークアップから始まり、現在は React や TypeScript を使ったコンポーネント実装をすることが多いです。

淡々と実装するだけではなくコミュニケーションを取りながら、チームとしてプロジェクトを前に進めることを意識しています。

最近は会社の成長へのコミットに関心があり、組織・チーム全体で強まるためにはどうするのだろう?ということを考えています。