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
mikan
December 13, 2023
Technology
0
170
マルチモジュール懐疑派だったかつての自分に送る マルチモジュールの効能
https://karabiner.connpass.com/event/302850/
mikan
December 13, 2023
Tweet
Share
More Decks by mikan
See All by mikan
Modeling UiEvent
mikanichinose
0
16
UIの構成要素に関する考察
mikanichinose
0
23
再考: 監視可能オブジェクト
mikanichinose
0
36
書評: 単体テストの考え方/使い方
mikanichinose
0
190
ComposeでリストUIをDraggableにする方法
mikanichinose
0
930
Composeのライフサイクル対応を支援するLifecycleEventEffectの紹介
mikanichinose
1
510
Composeでカスタムレイアウトを組むときの気持ち
mikanichinose
0
330
Other Decks in Technology
See All in Technology
推薦システムを本番導入する上で一番優先すべきだったこと~NewsPicks記事推薦機能の改善事例を元に~
morinota
0
120
AIエージェントを現場に導入する目線とは
masahiro_nishimi
1
1.5k
データベース研修 DB基礎【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
210
エンジニア向け会社紹介資料
caddi_eng
14
220k
AOAI Dev Day LLMシステム開発 Tips集
hirosatogamo
15
3.6k
RAGのサービスをリリースして1年3ヶ月が経ちました
segavvy
4
900
サービスの持続的な成長と技術負債について
siva_official
PRO
10
4.4k
20240717_イケコパ代表Copilot_in_Teams会社でこう使ってます
ponponmikankan
2
430
ギークの理想が7つ集まるエムスリーで夢を叶えよう - エムスリー株式会社
m3_engineering
1
260
たくさん本を読んだけど 1年後には綺麗サッパリ!を乗り越えて 学習の鬼になるぞ👹
yum3
0
160
ペパボのオブザーバビリティ研修2024 説明資料
kesompochy
0
1.1k
頼られるのが大好きな 皆さんへ - 支援相手との期待の合わせ方、突き放し方 -/For_people_who_like_to_be_relied_on
naitosatoshi
1
290
Featured
See All Featured
Scaling GitHub
holman
458
140k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
245
1.2M
The Language of Interfaces
destraynor
151
23k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
121
18k
Practical Orchestrator
shlominoach
185
10k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
34
1.9k
The Power of CSS Pseudo Elements
geoffreycrofte
64
5.2k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
35
6.3k
Being A Developer After 40
akosma
72
580k
A designer walks into a library…
pauljervisheath
201
24k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
353
29k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
19k
Transcript
マルチモジュール懐疑派だったかつての自分に送る マルチモジュールの効能 モバイルアプリLT 会 一瀬喜弘(@mikanIchinose)
自己紹介 object Mikan { val name = " 一瀬喜弘" val
company = "karabiner.tech" val work = Engineer.Android val hobby = listOf( " 漫画", " アニメ", " ゲーム", " 折り紙", "OSS 開発・コントリビュート", ) }
巷ではマルチモジュールが流行ってるっぽいけど なんであんな複雑そうな構成が流行るのか分からん
とかつて思っていた自分の疑問に答える形式で マルチモジュール構成の利点を解説
Q1 モジュールに分けて何が嬉しいの? Q2 モジュールを 分けると プロダクションコード以外の ファイルが 増えて、 管理コストが 増すのでは?
Q3 開発スピードが落ちそう Q4 モジュールを上手に分けられる気がしない
Q1 モジュールに分けて何が嬉しいの?
1 依存の方向をビルド構成によって定義できる モノモジュール 何が何に依存しててもおかしくない
1 依存の方向をビルド構成によって定義できる マルチモジュール ビルド構成によって依存関係を厳密に規定できる feature-module はdata-module のコンポーネントを、domain-module はfeature- module のコンポーネントをインポートすることが不可能
// feature/build.gradle.kts implementation(project(":domain")) // domain/build.gradle.kts implementation(project(":data"))
2 関係ないコンポーネントが思考を遮らない モノモジュール . └── app └── src ├── data
│ ├── AuthRepository.kt │ ├── AuthRepositoryImpl.kt │ ├── UserRepository.kt │ └── UserRepositoryImpl.kt ├── domain │ ├── GetUserUseCase.kt │ └── LoginUseCase.kt └── ui ├── LoginScreen.kt ├── LoginViewModel.kt ├── SplashScreen.kt └── SplashViewModel.kt
2 関係ないコンポーネントが思考を遮らない マルチモジュール . ├── app │ └── src │
└── MainActivity.kt ├── data-api │ └── src │ └── data │ ├── AuthRepository.kt │ └── UserRepository.kt ├── data-impl │ └── src │ └── data │ ├── AuthRepositoryImpl.kt │ └── UserRepositoryImpl.kt ├── domain │ └── src │ └── domain │ ├── GetUserUseCase.kt │ └── LoginUseCase.kt └── feature ├── login │ └── src │ └── feature │ └── login │ └── ui │ ├── LoginScreen.kt │ └── LoginViewModel.kt └── splash └── src └── feature └── splash └── ui ├── SplashScreen.kt └── SplashViewModel.kt
3 モジュールに分けられる構造 = 良い設計 モジュールとして切り離すことができるということは以下を達成しないといけないので自ずと良い設計になる 疎結合 共通パーツは共通なモジュール(shared, common, core) として切り出したくなる
機能間の依存がなくなるのでfeature-module 内の変更がモジュールで完結する 循環依存しない コンパイル不可能
モジュールを 分けると プロダクションコード以外の ファイルが 増えて、
管理コストが 増すのでは?
マルチモジュールを触りだしたころはそう思っていた
1 新しくモジュールを作るという作業は面倒 new module したときにウィザードで正しい項目を入力できているだろうか Package name とか入力するの地味にめんどくさい あとから修正したくなったときにどこまで修正したら完了なのか分からん hoge/src/main/
hoge/fuga hoge/src/main/AndroidManifest.xml hoge/build.gradle(.kts) やること自体はそこまで多くないので割とすぐ習熟する ` `
ソースコード以外はほとんど変化することがないので 作ってしまえばほぼ終わり
2 ビルド設定の共通化という難所 gradle に対する習熟度が求めれる 手段が幾通りもありどれに手を出そうか迷う 共通構成を記載したgradle ファイルを作り、各build.gralde でapply する とくにキャッシュされるわけではないのでビルドタイムには貢献しない
Convention Plugin 共通処理をプラグインとして定義する
2 ビルド設定の共通化という難所 Convention Plugin precompiled script plugin .gradle.kts ファイルで書く 依存やバージョンをKotlin
ファイルで管理 → Version Catalog が主流になったので不要かも standalone gradle plugin .kt ファイルで書く せっかく依存をVersion Catalog で管理したのに文字列で指定しなくちゃいけなくなるので微妙な気持 ち 最新のサンプル実装(nowinandroid) はこちらを使用している more information https://star-zero.medium.com/gradle のconvention-plugins-ba19a1332540 https://speakerdeck.com/jmatsu/gradle-convention-plugins
Q3 開発スピードが落ちそう
コードを書くスピードは落ちることもある
しかし、それとこれとはスコープの違う話
マルチモジュールは設計の道具 設計する = 戦略的思考 コードを書く = 戦術的思考
Q4 モジュールを上手に分けられる気がしない
アーキテクチャとか 設計系の 技術書で 勉強してください クリーンアーキテクチャ 単体テストの考え方/ 使い方
iOS アプリ設計パターン入門 ソフトウェアアーキテクチャの基礎 ー エンジニアリングに基づく体系的アプローチ ドメイン駆動設計
バックエンドや フロントエンドの トレンドも 参考になる バックエンド モノリス モジュラーモノリス
マイクロサービス フロントエンド コンポーネント指向 Atomic Design
まとめ Q1 モジュールに分けることの嬉しさ → 良い設計をこころがけるようになる Q2 管理コストの増大 → あまり変化しないのでコストにならない Q3
開発スピードの低下 → 頭の使い方が違うだけなので慣れれば低下しない Q4 モジュール分割難しい → アーキテクチャとか設計の勉強して