今までの開発手順

コンポーネント単位で開発してきた。アトミックデザインを念頭に開発し、各コンポーネントを組み立て、一枚のページを構築させまた、ユニットテストた結合テストといったバグを早期に発見できるように開発してきたが、タイトルのことを調べるうちに違和感を感じた。

自分のやり方を改善していくべきなのかと思いました。
そのアウトプットの内容をここに記入していこうと思う。

Component Driven Development - CDD -

端的に言いますと「ボトムアップ」の開発プロセスで進めていく手法になります。
コンポーネントとは、ある責務を持った部品です。
その部品たちを小さな単位から開発していき、小さなコンポーネントを中くらいのコンポーネントに組み立てていき、そしてページを作り上げプロジェクトに統合していきます。
小さな単位はユーザーにとって特に重要ではないがプロジェクト統合までいくとユーザーにとって必要な情報があります。

少し抽象度が高いですが、自分の理解の仕方なのでご了承ください。ただポイントは押させられていると思います。

このコンポーネントを構築していくのに役立つのが、Atomic Designとゆう概念で、コンポーネントが持っている責務がメンタルモデルのフローのどこかに属します。

なので、あくまでもページベースの開発ではなく、コンポーネントベースの開発とゆうことです。

メリット

品質

コンポーネントを小さな単位で構築し、関連している状態を引き合うことで、違ったストーリーでコンポーネントが動作することを検証確認します。

耐久性

UIの各種テストを各シナリオで行うことができるので早期にバグを発見することができます。

速度

コンポーネントの組み立ての際に再利用を繰り返しますのでスピーディに行うことが可能です。

効率

複数人でのUI開発に際し、個別でコンポーネントの構築していきますので、並列的に進行していきます。

まとめ

長くなるので他でまた書こうと思いますが、コンポーネントを開発していくにあたってStoryBookを使うことが今では一般化しているかと思います。こちらを使うことで、少ない作業でコンポーネントを数多く構築することができ、テストも同時に行うことができますし、様々なシナリオで機能することも考慮し構築できますので、柔軟性の高いコンポーネント構築も容易に開発することが可能です。
そして、アジャイル開発時に有効に働きます。小さな単位で構築していきますので、変更や追加などの突発的な要望にも応えることが可能です。

ただ、デメリットとしては、一線を引かないといつまでも続いてしまうとゆうところが挙げられるのと、ページ単位で構築していく開発には不向きな面もあります。

なので、メリットデメリットをしっかり考えた上で、こういった開発手法を検討した方がいいでしょう。

今回調べて改めて、考える機会に出会うことができました。
フロントエンドエンジニアとして従事しているのですが、これからもUI開発に関わる技術などの進歩がありますのでしっかりキャッチアップしていこうと思います。