SANDFISH FACTORY

技術ブログです。python・vuejsを愛でる日々について綴ります

アトミックデザインでの失敗から辿り着いたSmartphone based な Atomic Design

はじめに

久しぶりの投稿です。
私事ですが、11月あたりから転職活動始めていて、ようやく転職先が決まってひと段落をついた今日この頃です。

今回はいつもと違って、アトミックデザインで失敗してしまった話とそこから導き出した考え方を書きたいと思います。

正直、これはデザインをきちんと学んでいないただのエンジニアの私が、デザインををきちんと把握している人と会話できる状態に持っていくためのものです。
アトミックデザイン初心者でイメージ湧かない方のファーストステップの考え方として見てもらえればと思います。

アトミックデザインって?

画面を構成する要素を、原子(Atom)分子(Molecule)有機体(Organism)テンプレート(Templates)ページ(Pages)の5つの階層に分け、UIをこれらの要素を組み合わせて設計する方法で、アメリカのブラッド・フロスト氏が考案・提唱した方法です。

すでに皆さん検索済みだと思いますが、DeNAさんのブログが分かりやすいです。ここでは割愛します。

アトミックデザインで失敗した話

何を失敗したか?

アトミックデザインは前述の通り、UIを設計する方法・考え方です。

初めてこの考え方を導入したとき、コンポーネントを整理していくことに注力してしまったため、業務ロジックをどこで実現するべきかが定めずに突っ走ってしまいました。。。
その結果、もの凄いスパゲッティコードが出来上がり、絡まりすぎて小麦粉団子になってました。

密結合なコンポーネント構成

もう、これがこの失敗の一番のつらみです。
Atom、Molecule、Organismの各所からaction、getterが呼ばれてデータを変更するように出来上がってしまったんですよ。
どこでデータが変わっているのか、なんでこの分岐があるのか、後で見直したら、もう訳が分からなくなっていました。
さながら、GOTO文が乱立していて大変だったという時代のようなコードでした。

大失敗を経て学んだこと

これはきちんとアトミックデザインの位置付けを理解して、適切な指針を定めていなかったことだなと思いました。

  • アトミックデザインはあくまでもUI設計の考え方を提示してくれる
  • アトミックデザインを浅く理解した状態では、業務ロジックについて別の考え方がないときちんと整理できない

私の指針:Smartphone based な Atomic Design

スマホ画面を軸に整理する

これはスマホ画面に最適化されたデザインを行うのではなく、「コンポーネントを整理するときスマホ画面を軸に考えたら悩まなかったよ」という一つの指針です。

スマホの画面構成って基本、縦長で各要素がスタックしている構成だと思っています。
パソコンやタブレットの画面で頭の中を整理すると、横の配置で表現することが出てくるため、2次元で考えると思います。
スマホの画面にすることで縦画面をどこで線を引くかにすることで、考えるべき次元を1つ減らした状態で整理できるので個人的にはスッキリしました。

f:id:sandfish03:20200126134810p:plain

ラフな画面デザインからコンポーネントの整理をしていく際、以下の順番で行ってみました。

  1. 画面を単体で意味をなす要素を分割して整理する(Organism)
  2. Organismを俯瞰してみて、機能として最小単位で部品を整理する(Atom
  3. Atom、Moleculeの要素をもとに動作でグルーピングする(Molecule)

f:id:sandfish03:20200126144440p:plain

メリット

再利用可能なコンポーネントができた

はじめは、5つの階層に分けるんだと意識しすぎていたため、変な構成で分かれてしまっていました。
Moleculeは少し融通がきく分け方だと考えた方が再利用のできるコンポーネントができて良かったと思っています。

業務ロジックはpagesに紐付ける

Organismを俯瞰してAtomに分解しているので、機能としての振る舞いでの制御しかないため業務ロジックを組み込めなくなりました。
組み込もうとするととても複雑な処理になるためです。
その結果、Organismの振る舞いをデータで制御するようになるため、上位コンポーネントで業務ロジックを実装するようになりました。 アトミックデザインの役割からするとPageで必要なデータを操作をするようになりました。

デメリット

データを受け渡すため冗長なコードは残る

Vue.jsの場合だと、vuexで保持しているStateを上位コンポーネントからデータをを伝播するように実装するため、propとemitでデータをバケツリレーするようになり、似たコードがとても増えました。
こちらについては良い解決方法が私自身わかっていませんが、Organism以下のコンポーネントでデータ操作を除去した方が分かりやすくなったので、このデメリットはある程度享受する必要があるかなと思っています。

まとめ

今回の投稿は一つの考え方の整理で正しい設計の仕方ではないと思っています。
エンジニアとして実装する側とデザインを考える方と会話するための一助となればと思い、まとめました。