複雑化したcomponent群と向き合う / #241106_plk_frontend

Transcript

1. © LayerX Inc. 複雑化したcomponent群と向き合う 2024/11/06 @プレイド/LayerX/ナレッジワーク_Webフロントエンドを軸に、幅を広げたエンジニアたちの仕事
2. 目次 Agenda • 自己紹介 • 複雑化って・・？ • 向き合う • 終わりに
3. 自己紹介
4. © LayerX Inc. 4 三角 亮太(delta） 自己紹介 • 株式会社LayerX ◦ 2024/04〜バクラク申請/経費精算 • 好きな食べ物: うどん・みかん
5. 5 © LayerX Inc. 事業紹介 稟議・支払申請・経費精算 仕訳・支払処理効率化 法人カードの発行・管理 帳票保存・ストレージ 帳票発行 * 経費精算のSlack連携は申請内容の通知のみ ・AIが領収書を５秒でデータ化 ・スマホアプリとSlack連携あり ・領収書の重複申請などミス防止機能 ・AIが請求書を５秒でデータ化 ・仕訳・振込データを自動作成 ・稟議から会計までスムーズに連携 ・年会費無料で何枚でも発行可 ・インボイス制度・電帳法対応 ・すべての決済で1%以上の還元 ・AIが書類を5秒でデータ化 ・あらゆる書類の電子保管に対応 ・電子取引・スキャナ保存に完全対応 ・帳票の一括作成も個別作成も自由自在 ・帳票の作成・稟議・送付・保存を一本化 ・レイアウトや項目のカスタマイズも可能
6. 6 © LayerX Inc. 事業紹介 稟議・支払申請・経費精算 仕訳・支払処理効率化 法人カードの発行・管理 帳票保存・ストレージ 帳票発行 * 経費精算のSlack連携は申請内容の通知のみ ・AIが領収書を５秒でデータ化 ・スマホアプリとSlack連携あり ・領収書の重複申請などミス防止機能 ・AIが請求書を５秒でデータ化 ・仕訳・振込データを自動作成 ・稟議から会計までスムーズに連携 ・年会費無料で何枚でも発行可 ・インボイス制度・電帳法対応 ・すべての決済で1%以上の還元 ・AIが書類を5秒でデータ化 ・あらゆる書類の電子保管に対応 ・電子取引・スキャナ保存に完全対応 ・帳票の一括作成も個別作成も自由自在 ・帳票の作成・稟議・送付・保存を一本化 ・レイアウトや項目のカスタマイズも可能
7. © LayerX Inc. 7 基本的な機能 2021年の4月リリースのNuxt製のアプリ 支払申請・購買申請・経費精算などなど複数の申請種別の申請・承認を扱うプロダクト - 申請種別ごとにいろんな種類のvalidationがあったり、 - 設定で色々経路をいじれたり、 - OCRでデータを読み込んだり とにかく場面場面でいろんな入力が入ってきてハンドリングが必要なプロダクトです バクラク申請経費精算について
8. 複雑化って・・？
9. © LayerX Inc. 9 主にこの二つ 1. ドメインの複雑さと、リリース時には一般的だったatomic designベースのディレクトリ構造の相性の 悪さ 2. リリース時にNuxtが対応していたVue２系から、Vue3系へ移行する難しさ 複雑化したって何？
10. © LayerX Inc. 10 色々な申請種別を扱うという複雑なドメインが atomic designのパーツを下位のレイヤーから組み立てる思想と合わせにくかった • 下位のcomponentは不要な共通化が行われ再利用・修正が難しい ◦ 例： すごく汎用的な<TextInput />みたいなものが存在していた ◦ 実際はvalidation、クリックした時の挙動、入力した時の挙動までとにかく多岐にわたる ◦ 色々なロジックに対応するためpropsをたくさん受け取って何をするcomponentなのか分か らない • 上位のcomponentは責務とともに実装も膨らむ ◦ サーバからデータを取る、propsに渡すデータ・関数を作成するで実装が膨らむ atomic designとどう相性が悪かったのか
11. © LayerX Inc. 11 Vue2からVue3への移行の難しさ • Vue2時代の型との相性の悪さを引きずる ◦ Vue2時代は型checkを全て通すことをやっておらずその余波でせっかく型を付け ても正しくチェックができないことが多数 • Options APIからComposition APIを使ってcomposableへロジックの切り出しを したいが元々の実装箇所が多くて置き換えきれていない
12. © LayerX Inc. 12 1. 😢ドメインの複雑さとatomic designベースのディレクトリ構造の相性の悪さ a. 😢下位のcomponentの不要な共通化 b. 😢上位のcomponentの責務が大きくなりでかすぎるcomponentがいる 2. 😢vue２からvue3への移行の難しさ a. 😢vue2時代の型の相性の悪さを引きずって型チェックができていない b. 😢options APIとcomposition APIの混在 この２大巨頭によって思わぬところに影響が出て実装がとても難しいうえに 時間が経つにつれて悪化の一途をたどっている😢😢😢 複雑な状況まとめ
13. 向き合う
14. © LayerX Inc. 14 立ち向かうための作戦 いきなり大きな改善はせず小さく始める (事業フェーズも踏まえつつ)大きな改善を入れるより普段の開発で 機能追加のスピードを落とさずにコスパよく効く部分にテコ入れする • ディレクトリベースの漸進的な改善 • 型エラーを全て直す
15. © LayerX Inc. 15 ディレクトリベースの漸進的な改善 atomic designベースのディレクトリに機能単位のディレクトリを新しく切った 狙い 1. 😢→☺ドメインの複雑さとatomic designベースのディレクトリ構造の相性の悪さ a. 😢→☺下位のcomponentの不要な共通化 b. 😢→☺上位のcomponentの責務が大きくなりでかすぎるcomponentがいる 新規のものは基本的にfeatures/に入れるように • 明らかに汎用的なもの以外はfeaturesに入れて過度の汎用化を防いだ • featuresに閉じたロジックはcomposableを経由するようにして上位の componentの肥大化を防いだ
16. © LayerX Inc. 16 ディレクトリベースの漸進的な改善 現実 1. 😢→😢ドメインの複雑さとatomic designベースのディレクトリ構造の相性の悪さ a. 😢→☺下位のcomponentの不要な共通化 b. 😢→😢上位のcomponentの責務が大きくなりでかすぎるcomponentがいる 新しい下位のcomponentによる複雑さは増えなくなった☺ 上位のcomponentは責務が大きいまま😢 だけど責務が膨らんで行くことは少なくなった☺
17. © LayerX Inc. 17 力あるのみ • 根気のあるチームメンバーの手によってそれはもうたくさんあった型エラーが0に・・😭 • 進め方は色々工夫してはいたものの型エラーが残っていると伝播してすぐ増えてしまうので 何だかんだ時間と気持ちの戦い・・ • ただただ偉業 型エラーを全て直す 予定通りの結果 • 😢→😐vue２からvue3への移行の難しさ ◦ 😢→☺☺vue2時代の型の相性の悪さを引きずって型チェックができていない ◦ 😢options APIとcomposition APIの混在
18. © LayerX Inc. 18 1. 😢→😢ドメインの複雑さとatomic designベースのディレクトリ構造の相性の悪さ a. 😢→☺下位のcomponentの不要な共通化 b. 😢→😢上位のcomponentの責務が大きくなりでかすぎるcomponentがいる 2. 😢→😐vue２からvue3への移行の難しさ a. 😢→☺☺vue2時代の型の相性の悪さを引きずって型チェックができていない b. 😢options APIとcomposition APIの混在 複雑さの現在地
19. © LayerX Inc. 19 ここまで比較的短期でできることをやってきた けど残りに対応していこうとなるとそれなりに腰を据えて取り組まないといけない 事業とコードベースの質どっちも一緒にレベルアップしていきたいけど、なかなか難しい 知恵を貸してください🥺 めちゃくちゃ道半ば
20. 終わりに
21. © LayerX Inc. 21 ディレクトリ設計は今日からでもできる取り組みなので同じ問題抱えてる人いたら是非 同じような悩みがある人いたらお話ししましょう 終わりに