Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
フロントエンド_最強ディレクトリ構成
Search
hatsune
December 07, 2022
Programming
5.3k
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
フロントエンド_最強ディレクトリ構成
hatsune
December 07, 2022
More Decks by hatsune
See All by hatsune
Vue_CLIプロジェクトにViteを導入検討してみた
kitsuneeee
1
8.1k
Vue.js + TypeScriptによる 新規サービス開発の振り返り/frontend-looking-back
kitsuneeee
4
2.2k
コンポーネント間のデータやりとりを色々試してみた.pdf
kitsuneeee
0
530
Other Decks in Programming
See All in Programming
Apache Hive: そしてCloud Native Lakehouseへ
okumin
1
200
霧の中の代数的エフェクト
funnyycat
1
450
全PRの83%がAIレビューだけでマージできるようになった開発組織はその後どうなったか
athug
0
1k
Apache Hive: Toward a Cloud Native Lakehouse
okumin
0
170
AIが無かった頃の素敵な出会いの話
codmoninc
1
340
ドリフトを絶対に許さない(?)CDK運用 / CDK Ops with Zero Tolerance for Drifts (?)
akihisaikeda
1
140
ここ半年くらいでAIに作らせたR用ツール
eitsupi
0
360
Claude Opus 4.6以後の受託開発エンジニアの変化(Claude Code開発ノウハウ大公開スペシャルbyクラスメソッド)
iidatakuma
1
930
20260722_microCMSで考える、AI時代のコンテンツ運用設計
yosh1
0
190
ルールを書いて終わらせないハーネスエンジニアリング
yug1224
4
1.8k
わからない話を追いかけたら、プログラミング言語を作る側にいた
ydah
2
310
そこに3びきプロダクトがいるじゃろう——生成AI時代における“価値が届かない理由”の構造
kosuket
0
370
Featured
See All Featured
GitHub's CSS Performance
jonrohan
1033
470k
Thoughts on Productivity
jonyablonski
76
5.3k
Neural Spatial Audio Processing for Sound Field Analysis and Control
skoyamalab
0
390
Designing for humans not robots
tammielis
254
26k
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
470
Designing Dashboards & Data Visualisations in Web Apps
destraynor
232
55k
16th Malabo Montpellier Forum Presentation
akademiya2063
PRO
0
310
Leo the Paperboy
mayatellez
8
2k
A Tale of Four Properties
chriscoyier
163
24k
Speed Design
sergeychernyshev
33
2k
Collaborative Software Design: How to facilitate domain modelling decisions
baasie
1
270
4 Signs Your Business is Dying
shpigford
187
22k
Transcript
フロントエンド 最強ディレクトリ構成 株式会社ラクス 勤怠開発2課 北嶋初音
index • 発表経緯 • 開発フェーズによる特徴 • 利用技術 • ディレクトリ構成見直し •
まとめ
発表経緯 • 楽楽勤怠のリリースから約2年 • 開発も運用フェーズへと移行しつつある • ディレクトリ設計の見直しもたびたび必要があった • 設計方針がある程度固まってきたので共有 •
経緯や具体的な移行内容をまとめておく
開発フェーズによる特徴 初期 開発スピード重視 • 共通化 ◦ 1箇所直したらで全部直って欲 しい • 機能要件が満たせればOK
現在 品質(保守性)重視 • 責務の分割 ◦ デグレを防止したい ◦ 修正の影響箇所を絞りたい • テストコードも書きたい
利用技術 • Vue.js(2系) • Vuex • TypeScript • Axios •
Jest • Testing Library • Storybook ※今回分かっておけば良い部分のみ記載
ディレクトリ構成見直し:導入 src/ ├── app/ │ ├── components/ │ │ ├──
base/ │ │ ├── pages/ │ │ └── parts/ │ ├── repositories/ │ ├── stores/ │ └── types/ ├── stories/ └── tests/
ディレクトリ構成見直し:導入 src/ ├── app/ │ ├── components/ │ │ ├──
base/ → 複数画面で利用される 共通コンポーネント(.vue) │ │ ├── pages/ → 各画面のルートとなる 画面コンポーネント(.vue) │ │ └── parts/ → 各画面で利用される 部品コンポーネント(.vue) │ ├── repositories/ │ ├── stores/ │ └── types/ ├── stories/ └── tests/
ディレクトリ構成見直し:導入 src/ ├── app/ │ ├── components/ │ │ ├──
base/ │ │ ├── pages/ │ │ └── parts/ │ ├── repositories/ → API通信を行う関数をまとめたファイル( .repo.ts) │ ├── stores/ │ └── types/ ├── stories/ └── tests/
ディレクトリ構成見直し:導入 src/ ├── app/ │ ├── components/ │ │ ├──
base/ │ │ ├── pages/ │ │ └── parts/ │ ├── repositories/ │ ├── stores/ → API通信の結果など状態を保持しておく Vuexファイル(.store.ts) │ └── types/ ├── stories/ └── tests/
ディレクトリ構成見直し:導入 src/ ├── app/ │ ├── components/ │ │ ├──
base/ │ │ ├── pages/ │ │ └── parts/ │ ├── repositories/ │ ├── stores/ │ └── types/ → TypeScriptの型情報を記載しておくファイル( .type.ts) ├── stories/ └── tests/
ディレクトリ構成見直し:導入 src/ ├── app/ │ ├── components/ │ │ ├──
base/ │ │ ├── pages/ │ │ └── parts/ │ ├── repositories/ │ ├── stores/ │ └── types/ ├── stories/ → storybookによるコンポーネントカタログのファイル( .stories.ts) └── tests/
ディレクトリ構成見直し:導入 src/ ├── app/ │ ├── components/ │ │ ├──
base/ │ │ ├── pages/ │ │ └── parts/ │ ├── repositories/ │ ├── stores/ │ └── types/ ├── stories/ └── tests/ → Jest, Testing Library によるテストコードのファイル( .spec.ts)
ディレクトリ構成見直し:導入 page part base store repository logic test sotires logic
test component test
ディレクトリ構成見直し:問題点① src/ ├── app/ │ ├── components/ │ │ ├──
base/ │ │ ├── pages/ │ │ └── parts/ → どの画面で使われてるのか分かりにくい。。 │ ├── repositories/ │ ├── stores/ → どの画面で状態が変更されるのか追いにくい。。 │ └── types/ ├── stories/ └── tests/
ディレクトリ構成見直し:問題点① src/ ├── app/ │ ├── components/ │ │ ├──
base/ │ │ ├── pages/ │ │ └── parts/ │ ├── repositories/ │ ├── stores/ │ └── types/ ├── stories/ → どのコンポーネントに対して実装済みか分かりにくい。。 └── tests/ → どのコンポーネントに対して実装済みか分かりにくい。。
ディレクトリ構成見直し:問題点① src/ ├── app/ │ ├── components/ │ │ ├──
base/ │ │ ├── pages/ │ │ └── parts/ │ ├── repositories/ │ ├── stores/ │ └── types/ ├── stories/ └── tests/ どの画面・どのコンポーネント に所属しているのかが分かれば良さそう ↓ pageコンポーネント中心に集めてみる
ディレクトリ構成見直し:partsファイル components/ ├── pages/ │ └── pc/ │ └── admin/
│ └── department-list/ │ └── AdminDepartmentListPc.vue └── parts/ └── pc/ └── admin/ └── department-list/ └── admin-department-form/ └── AdminDepartmentForm.vue components/ └── pages/ └── pc/ └── admin/ └── department-list/ ├── AdminDepartmentListPc.vue └── parts/ └── department-form/ └── DepartmentForm.vue before after
ディレクトリ構成見直し:partsファイル components/ ├── pages/ │ └── pc/ │ └── admin/
│ └── department-list/ │ └── AdminDepartmentListPc.vue └── parts/ └── pc/ └── admin/ └── admin-department-form/ └── AdminDepartmentForm.vue components/ └── pages/ └── pc/ └── admin/ └── department-list/ ├── AdminDepartmentListPc.vue └── parts/ └── department-form/ └── DepartmentForm.vue before after • 利用される画面が分かりや すくなった • フォルダ名やファイル名が シンプルになった • 階層を合わせる必要もなく なった
ディレクトリ構成見直し:storeファイル app/ ├── components/ │ └── pages/ │ └── pc/
│ └── admin/ │ └── department-list/ │ └── AdminDepartmentListPc.vue └── stores/ └── Department.ts components/ └── pages/ └── pc/ └── admin/ └── department-list/ ├── AdminDepartmentListPc.vue └── store/ └── AdminDepartmentListPc.store.ts before after
ディレクトリ構成見直し:storeファイル app/ ├── components/ │ └── pages/ │ └── pc/
│ └── admin/ │ └── department-list/ │ └── AdminDepartmentListPc.vue └── stores/ └── Department.ts components/ └── pages/ └── pc/ └── admin/ └── department-list/ ├── AdminDepartmentListPc.vue └── store/ └── AdminDepartmentListPc.store.ts before after • 更新される画面が分かりや すくなった • グローバルなStoreから画 面専用のStoreになったの で、他画面の影響を受けな くなった
ディレクトリ構成見直し:typeファイル app/ ├── components/ │ └── pages/ │ └── pc/
│ └── admin/ │ └── department-list/ │ └── AdminDepartmentListPc.vue └── types/ └── department.type.ts components/ └── pages/ └── pc/ └── admin/ └── department-list/ ├── AdminDepartmentListPc.vue └── AdminDepartmentListPc.type.ts before after
ディレクトリ構成見直し:specファイル src/ ├── app/ │ └── components/ │ └── pages/
│ └── pc/ │ └── admin/ │ └── department-list/ │ └── AdminDepartmentListPc.vue └── tests/ └── app/ 〜 省略 〜 └── AdminDepartmentListPc.it.spec.ts components/ └── pages/ └── pc/ └── admin/ └── department-list/ ├── AdminDepartmentListPc.vue └── AdminDepartmentListPc.it.spec.ts before after
ディレクトリ構成見直し:stories src/ ├── app/ │ └── components/ │ └── pages/
│ └── pc/ │ └── admin/ │ └── department-list/ │ └── AdminDepartmentListPc.vue └── stories/ └── app/ 〜 省略 〜 └── AdminDepartmentListPc.stories.ts components/ └── pages/ └── pc/ └── admin/ └── department-list/ ├── AdminDepartmentListPc.vue └── AdminDepartmentListPc.stories.ts before after
ディレクトリ構成見直し:まとめ① components/ └── pages/ └── pc/ └── admin/ └── department-list
├── AdminDepartmentListPc.vue ├── AdminDepartmentListPc.type.ts ├── AdminDepartmentListPc.it.spec.ts ├── AdminDepartmentListPc.stories.ts ├── parts │ └── department-form │ └── DepartmentForm.vue └── store └── AdminDepartmentListPc.store.ts after pageコンポーネント中心に集めて 各ファイルの利用箇所が分かりや すくやった (責務の分離もできた)
ディレクトリ構成見直し:問題点② page part base store repository logic test sotires logic
test component test ビジネスロジックが 多くなりがち テストが書きにくい ビジネスロジックが 多くなりがち テストが書きにくい
ディレクトリ構成見直し:問題点② page part base store repository logic test sotires logic
test component test modules modules • ビジネスロジックを抜き出す階層を作成 • export/importでテストも書くやすくする
ディレクトリ構成見直し:modules components/ └── pages/ └── pc/ └── admin/ └── department-list
├── AdminDepartmentListPc.vue ├── AdminDepartmentListPc.type.ts ├── AdminDepartmentListPc.it.spec.ts ├── AdminDepartmentListPc.stories.ts ├── parts │ └── department-form │ └── DepartmentForm.vue └── store └── AdminDepartmentListPc.store.ts components/ └── pages/ └── pc/ └── admin/ └── department-list ├── AdminDepartmentListPc.vue ├── AdminDepartmentListPc.type.ts ├── AdminDepartmentListPc.it.spec.ts ├── AdminDepartmentListPc.stories.ts ├── AdminDepartmentListPc.modules.ts ├── AdminDepartmentListPc.modules.spec.ts ├── parts │ └── department-form │ └── DepartmentForm.vue └── store └── AdminDepartmentListPc.store.ts before after
ディレクトリ構成見直し:modules components/ └── pages/ └── pc/ └── admin/ └── department-list
├── AdminDepartmentListPc.vue ├── AdminDepartmentListPc.type.ts ├── AdminDepartmentListPc.it.spec.ts ├── AdminDepartmentListPc.stories.ts ├── parts │ └── department-form │ └── DepartmentForm.vue └── store └── AdminDepartmentListPc.store.ts components/ └── pages/ └── pc/ └── admin/ └── department-list ├── AdminDepartmentListPc.vue ├── AdminDepartmentListPc.type.ts ├── AdminDepartmentListPc.it.spec.ts ├── AdminDepartmentListPc.stories.ts ├── AdminDepartmentListPc.modules.ts ├── AdminDepartmentListPc.modules.spec.ts ├── parts │ └── department-form │ └── DepartmentForm.vue └── store └── AdminDepartmentListPc.store.ts before after • pageコンポーネントの肥大 化を防げた • ロジックを抜き出したおかげ でテストも書きやすくなった
ディレクトリ構成見直し:Pros/Cons Pros • 各ファイルの影響箇所が分かりやす くなった • ロジック抜き出しによってコンポーネ ントやStoreの肥大化を防げた • テストも書きやすくなった
Cons • 共通化が減るので実装工数は増え た • 実装漏れには気をつける必要があ る • 画面特有のものにするか、共通のも のにするかの判断が難しいものもあ る • 移行作業を行うには工数がかかる ◦ デグレチェック ◦ コンフリクト解消
まとめ • 開発フェーズによって適切な設計は異なる • 楽楽勤怠では品質(保守性)重視での設計見直しを行った • 画面コンポーネント中心の設計にすることで修正の影響範囲が分かり やすくなった • ビジネスロジックの抜き出し層を設けたおかげでテストも書きやすくなっ
た • 全て画面の持ち物にすることは不可能なので共通部分は消せない、使 い分けはしていく必要がある
ありがとうございました!