Slide 1

Slide 1 text

© LayerX Inc. 複雑化したcomponent群と向き合う 2024/11/06 @プレイド/LayerX/ナレッジワーク_Webフロントエンドを軸に、幅を広げたエンジニアたちの仕事

Slide 2

Slide 2 text

目次 Agenda ● 自己紹介 ● 複雑化って・・? ● 向き合う ● 終わりに

Slide 3

Slide 3 text

自己紹介

Slide 4

Slide 4 text

© LayerX Inc. 4 三角 亮太(delta) 自己紹介 ● 株式会社LayerX ○ 2024/04〜バクラク申請/経費精算 ● 好きな食べ物: うどん・みかん

Slide 5

Slide 5 text

5 © LayerX Inc. 事業紹介 稟議・支払申請・経費精算 仕訳・支払処理効率化 法人カードの発行・管理 帳票保存・ストレージ 帳票発行 * 経費精算のSlack連携は申請内容の通知のみ ・AIが領収書を5秒でデータ化 ・スマホアプリとSlack連携あり ・領収書の重複申請などミス防止機能 ・AIが請求書を5秒でデータ化 ・仕訳・振込データを自動作成 ・稟議から会計までスムーズに連携 ・年会費無料で何枚でも発行可 ・インボイス制度・電帳法対応 ・すべての決済で1%以上の還元 ・AIが書類を5秒でデータ化 ・あらゆる書類の電子保管に対応 ・電子取引・スキャナ保存に完全対応 ・帳票の一括作成も個別作成も自由自在 ・帳票の作成・稟議・送付・保存を一本化 ・レイアウトや項目のカスタマイズも可能

Slide 6

Slide 6 text

6 © LayerX Inc. 事業紹介 稟議・支払申請・経費精算 仕訳・支払処理効率化 法人カードの発行・管理 帳票保存・ストレージ 帳票発行 * 経費精算のSlack連携は申請内容の通知のみ ・AIが領収書を5秒でデータ化 ・スマホアプリとSlack連携あり ・領収書の重複申請などミス防止機能 ・AIが請求書を5秒でデータ化 ・仕訳・振込データを自動作成 ・稟議から会計までスムーズに連携 ・年会費無料で何枚でも発行可 ・インボイス制度・電帳法対応 ・すべての決済で1%以上の還元 ・AIが書類を5秒でデータ化 ・あらゆる書類の電子保管に対応 ・電子取引・スキャナ保存に完全対応 ・帳票の一括作成も個別作成も自由自在 ・帳票の作成・稟議・送付・保存を一本化 ・レイアウトや項目のカスタマイズも可能

Slide 7

Slide 7 text

© LayerX Inc. 7 基本的な機能 2021年の4月リリースのNuxt製のアプリ 支払申請・購買申請・経費精算などなど複数の申請種別の申請・承認を扱うプロダクト - 申請種別ごとにいろんな種類のvalidationがあったり、 - 設定で色々経路をいじれたり、 - OCRでデータを読み込んだり とにかく場面場面でいろんな入力が入ってきてハンドリングが必要なプロダクトです バクラク申請経費精算について

Slide 8

Slide 8 text

複雑化って・・?

Slide 9

Slide 9 text

© LayerX Inc. 9 主にこの二つ 1. ドメインの複雑さと、リリース時には一般的だったatomic designベースのディレクトリ構造の相性の 悪さ 2. リリース時にNuxtが対応していたVue2系から、Vue3系へ移行する難しさ 複雑化したって何?

Slide 10

Slide 10 text

© LayerX Inc. 10 色々な申請種別を扱うという複雑なドメインが atomic designのパーツを下位のレイヤーから組み立てる思想と合わせにくかった ● 下位のcomponentは不要な共通化が行われ再利用・修正が難しい ○ 例: すごく汎用的なみたいなものが存在していた ○ 実際はvalidation、クリックした時の挙動、入力した時の挙動までとにかく多岐にわたる ○ 色々なロジックに対応するためpropsをたくさん受け取って何をするcomponentなのか分か らない ● 上位のcomponentは責務とともに実装も膨らむ ○ サーバからデータを取る、propsに渡すデータ・関数を作成するで実装が膨らむ atomic designとどう相性が悪かったのか

Slide 11

Slide 11 text

© LayerX Inc. 11 Vue2からVue3への移行の難しさ ● Vue2時代の型との相性の悪さを引きずる ○ Vue2時代は型checkを全て通すことをやっておらずその余波でせっかく型を付け ても正しくチェックができないことが多数 ● Options APIからComposition APIを使ってcomposableへロジックの切り出しを したいが元々の実装箇所が多くて置き換えきれていない

Slide 12

Slide 12 text

© LayerX Inc. 12 1. 😢ドメインの複雑さとatomic designベースのディレクトリ構造の相性の悪さ a. 😢下位のcomponentの不要な共通化 b. 😢上位のcomponentの責務が大きくなりでかすぎるcomponentがいる 2. 😢vue2からvue3への移行の難しさ a. 😢vue2時代の型の相性の悪さを引きずって型チェックができていない b. 😢options APIとcomposition APIの混在 この2大巨頭によって思わぬところに影響が出て実装がとても難しいうえに 時間が経つにつれて悪化の一途をたどっている😢😢😢 複雑な状況まとめ

Slide 13

Slide 13 text

向き合う

Slide 14

Slide 14 text

© LayerX Inc. 14 立ち向かうための作戦 いきなり大きな改善はせず小さく始める (事業フェーズも踏まえつつ)大きな改善を入れるより普段の開発で 機能追加のスピードを落とさずにコスパよく効く部分にテコ入れする ● ディレクトリベースの漸進的な改善 ● 型エラーを全て直す

Slide 15

Slide 15 text

© LayerX Inc. 15 ディレクトリベースの漸進的な改善 atomic designベースのディレクトリに機能単位のディレクトリを新しく切った 狙い 1. 😢→☺ドメインの複雑さとatomic designベースのディレクトリ構造の相性の悪さ a. 😢→☺下位のcomponentの不要な共通化 b. 😢→☺上位のcomponentの責務が大きくなりでかすぎるcomponentがいる 新規のものは基本的にfeatures/に入れるように ● 明らかに汎用的なもの以外はfeaturesに入れて過度の汎用化を防いだ ● featuresに閉じたロジックはcomposableを経由するようにして上位の componentの肥大化を防いだ

Slide 16

Slide 16 text

© LayerX Inc. 16 ディレクトリベースの漸進的な改善 現実 1. 😢→😢ドメインの複雑さとatomic designベースのディレクトリ構造の相性の悪さ a. 😢→☺下位のcomponentの不要な共通化 b. 😢→😢上位のcomponentの責務が大きくなりでかすぎるcomponentがいる 新しい下位のcomponentによる複雑さは増えなくなった☺ 上位のcomponentは責務が大きいまま😢 だけど責務が膨らんで行くことは少なくなった☺

Slide 17

Slide 17 text

© LayerX Inc. 17 力あるのみ ● 根気のあるチームメンバーの手によってそれはもうたくさんあった型エラーが0に・・😭 ● 進め方は色々工夫してはいたものの型エラーが残っていると伝播してすぐ増えてしまうので 何だかんだ時間と気持ちの戦い・・ ● ただただ偉業 型エラーを全て直す 予定通りの結果 ● 😢→😐vue2からvue3への移行の難しさ ○ 😢→☺☺vue2時代の型の相性の悪さを引きずって型チェックができていない ○ 😢options APIとcomposition APIの混在

Slide 18

Slide 18 text

© LayerX Inc. 18 1. 😢→😢ドメインの複雑さとatomic designベースのディレクトリ構造の相性の悪さ a. 😢→☺下位のcomponentの不要な共通化 b. 😢→😢上位のcomponentの責務が大きくなりでかすぎるcomponentがいる 2. 😢→😐vue2からvue3への移行の難しさ a. 😢→☺☺vue2時代の型の相性の悪さを引きずって型チェックができていない b. 😢options APIとcomposition APIの混在 複雑さの現在地

Slide 19

Slide 19 text

© LayerX Inc. 19 ここまで比較的短期でできることをやってきた けど残りに対応していこうとなるとそれなりに腰を据えて取り組まないといけない 事業とコードベースの質どっちも一緒にレベルアップしていきたいけど、なかなか難しい 知恵を貸してください🥺 めちゃくちゃ道半ば

Slide 20

Slide 20 text

終わりに

Slide 21

Slide 21 text

© LayerX Inc. 21 ディレクトリ設計は今日からでもできる取り組みなので同じ問題抱えてる人いたら是非 同じような悩みがある人いたらお話ししましょう 終わりに