はじめに

ゆとり世代の中野です。

さっそくチャレンジについて書いていきます。

チャレンジする背景

• Atomic Designを導入して失敗してきた記録を残しておく
• ある程度いい感じにComponentの粒度を定義できたので残しておく

チャレンジ内容

• 考えを整理する

Atomic Designで失敗したこと

深く考えずに導入したこと

• 考え方はすごくシンプルでわかりやすいので深く考えずに導入できてしまうことでいくつもの弊害を生んでしまいAtomic Design難しいになった
• applicationの場合はDesign+Logicになるため複雑化した
• さらに複雑性が入ってくるとデザイナとエンジニアの協業のハードルが上がる
• 人によってComponentの粒度に対する認識が違うため作る人によって成果物が異なる

UIフレームワークのパーツをatomと定義したこと

• UIフレームワークの1つ1つのmoduleをatomと定義した
• 粒度がProductではなくUIフレームワークに依存してしまう
• あくまで粒度自体はProductで定義すべきもの

atomですべてのパターンを作ったこと

• すべてのパターンを作った
• 外からpropsを渡せるようにするべきでした

moleclues配下をフラットにしすぎたこと

• atomsと同じくmoleculesも再利用性できるため同じようにしたこと
• 組み合わせ使うという特性があるためatomと同じような構成にするには無理がある
• 必ずどこかでそれらの歪を吸収するところが出てくる

organizationsがmoleculesを組み立てる場所になっていたこと

• molecluesを再利用性しやすいように汎用的に作っていたのでここでComponentの組み立てを行っていました
• organizationはmoleculesを組み立てる場所ではなさそうです

organizationsがmoleculesの差別化があいまいだった

• 何がorganizationでmoleculesなのか定義があいまいで多くの混乱を生みました
• Atomic Designで特に難しいのはorganizationがmoleculesの切り分けでした

どうすればよかったのか

各レイヤーの定義を明確にする

• Componentには限定的Componentと汎用的Componentがあることを理解する
• 限定的Componentまで汎用的Componentに含めることで複雑性がマシマシになる
• この2つのComponentの存在を理解することで一気に設計難易度が下がった

各レイヤーの定義を決める

• 今開発しているProductでは以下のように明確に決めています

• 特にOrganizationsとMoleculesを関心事で分離することであいまいだった両者が明確に別物として認知できるようになりました

結論

なぜAtomic Designは難しいのか

• 概念のため具体的な方法論ではないため
• 人によって考え方が違うため共通の認識を作るのが難しい

なぜAtomic Designで失敗するのか

• 基本的な考え方はシンプルなので導入しやすい
• Logicが加わると難易度が急にあがる
• 明確な定義やルールがなくてもふんわりはじめられる

どうすればAtomic Designと仲良くなれるのか

• 導入時に明確に定義する
• 再定義し作り直す
• リファクタする

さいごに

• 現時点では一番納得できる定義が行えたと思っていますが今後もっといい方法がわかればUpdateします
• この記事にもっと早く出会えていればこんなに苦しむこともなかった気がする

AtomicDesign 境界線のひき方

AtomicDesign はコンポーネント粒度の指標として共有し易く、多くのプロジェクトで採用されています。しかしながら、その設計概念が先立ってしまい、いくらかの課題を抱えている場合があります。 多くの場合「粒度」だけを基準にしてしまい、 横断的コンテキストに「早期区分」 してしまっていることが直接的原因です。 ...

zenn.dev

yutanakano

WEBエンジニア

大阪生まれのゆとり世代です

趣味はバイクでツーリングに行くこと

愛車は Ninja ZX-25R SE KRT EDITION

Expoでプロダクトを作っています