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
190
マルチモジュール懐疑派だったかつての自分に送る マルチモジュールの効能
https://karabiner.connpass.com/event/302850/
mikan
December 13, 2023
Tweet
Share
More Decks by mikan
See All by mikan
ライブラリでしかお目にかかれない珍しい実装
mikanichinose
2
350
Strong Skipping Mode によってrecompositionはどう変わったのか
mikanichinose
0
170
Modeling UiEvent
mikanichinose
0
36
UIの構成要素に関する考察
mikanichinose
0
38
再考: 監視可能オブジェクト
mikanichinose
0
53
書評: 単体テストの考え方/使い方
mikanichinose
0
220
ComposeでリストUIをDraggableにする方法
mikanichinose
0
1.2k
Composeのライフサイクル対応を支援するLifecycleEventEffectの紹介
mikanichinose
1
640
Composeでカスタムレイアウトを組むときの気持ち
mikanichinose
0
370
Other Decks in Technology
See All in Technology
CysharpのOSS群から見るModern C#の現在地
neuecc
2
3.2k
ドメイン名の終活について - JPAAWG 7th -
mikit
33
20k
Python(PYNQ)がテーマのAMD主催のFPGAコンテストに参加してきた
iotengineer22
0
470
個人でもIAM Identity Centerを使おう!(アクセス管理編)
ryder472
3
200
【Pycon mini 東海 2024】Google Colaboratoryで試すVLM
kazuhitotakahashi
2
500
インフラとバックエンドとフロントエンドをくまなく調べて遅いアプリを早くした件
tubone24
1
430
テストコード品質を高めるためにMutation Testingライブラリ・Strykerを実戦導入してみた話
ysknsid25
7
2.6k
ノーコードデータ分析ツールで体験する時系列データ分析超入門
negi111111
0
410
オープンソースAIとは何か? --「オープンソースAIの定義 v1.0」詳細解説
shujisado
7
810
サイバーセキュリティと認知バイアス:対策の隙を埋める心理学的アプローチ
shumei_ito
0
380
AWS Lambda のトラブルシュートをしていて思うこと
kazzpapa3
2
170
第1回 国土交通省 データコンペ参加者向け勉強会③- Snowflake x estie編 -
estie
0
130
Featured
See All Featured
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
410
YesSQL, Process and Tooling at Scale
rocio
169
14k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
65k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
506
140k
Designing for humans not robots
tammielis
250
25k
The Invisible Side of Design
smashingmag
298
50k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Unsuck your backbone
ammeep
668
57k
RailsConf 2023
tenderlove
29
900
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
16k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
26
2.1k
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 モジュール分割難しい → アーキテクチャとか設計の勉強して