1K Views
September 27, 24
スライド概要
Chatworkアプリの マルチモジュール戦略 若江 照仁 2024年 9月18日
自己紹介 struct Profile { var 名前: String = "若江 照仁" var あだ名: String = "テリー" var 誕生日: String = "1984/12/24" var エンジニア歴: String = "3年" var 社歴: String = "1年" var 趣味: [String] = [ "娘と遊ぶ", "スノボ", "ギター", "ウィスキー" terry ] @terrypy6 }
CONTENTS 目次 01 | これまでのマルチモジュール化 02 | これからのマルチモジュール化
01 | これまでのマルチモジュール化
マルチモジュール化始動 (約2年前)
2年前の「Chatwork」アプリ ChatworkApp Features Feature1 CocoaPods OSS Library 1 OSS Library 2 Feature2 Domain Service Model ※実際はもっと複雑な構成ですが、 解説用に簡素化しています 6
マルチモジュール化によって解決したいこと 1. ビルド速度の改善 ● 依存関係が複雑で、1ファイル更新で1,000ファイル以上のビルドが走ることがよくある。 2. チームごとにモジュール担当領域を決め、リードタイムを短縮 ● 機能ごとにチームを分ける想定なので、チームごとに担当するモジュールを決めることで 責務を明確にすることができ、コンフリクトも発生がしづらくなる。 3. 依存関係の解決 ● 影響範囲を最小化することでコード品質が安定し、疎結合な状態も保ちやすくなる。 4. XcodeGenの廃止 ● ブランチを切り替えるとXcodeが落ちる。 7
ライブラリの管理をSwiftPackageManagerへ移行 ChatworkApp Features Feature1 CocoaPods OSS Library 1 OSS Library 2 Feature2 Domain 📦SwiftPackageManager Service 📦OSS Library 1 Model 📦OSS Library 2 8
分割後イメージ ChatworkApp ChatworkApp 依存 Features Feature1 📦Features Feature1 Feature2 Feature2 依存 Domain 📦Service Service 依存 Model 📦Model 9
DomainをTemporaryパッケージへ ChatworkApp Features 相互依存など 複雑な依存関係 Feature1 📦Temporary Feature2 Domain 丸ごと Domain Service Service Model Model 神マネージャー みたいな子 もいるよ♪ 10
FeaturesをFeaturesパッケージへ ChatworkApp 📦Features Features Feature1 Feature2 断念 📦Temporary Domain Storyboard内で利用している アセットやリソースの 共通化が難しい Service Model 11
既存のFeatureの移行について ChatworkApp 📦Features Feature3 Features Storyboard Storyboard SwiftUI Feature1 Feature2 SwiftUI化が 終わってからやる 📦Temporary Domain SwiftUI Service Model 12
現在の「Chatwork」アプリ ChatworkApp Features 依存 📦Features New!! Feature3 Feature1 Feature2 依存 📦Temporary Domain Service 極力増やさない Model 13
解決できたこと 1. ビルド速度の改善 ● 依存関係が複雑で、1ファイル更新で1,000ファイル以上のビルドが走ることがよくある。 2. チームごとにモジュール担当領域を決め、リードタイムを短縮 ● 機能ごとにチームを分ける想定なので、チームごとに担当するモジュールを決めることで 結果 責務を明確にすることができ、コンフリクトも発生がしづらくなる。 ビルド時間が半分程度に削減 3. 依存関係の解決 実施できたこと ● 影響範囲を最小化することでコード品質が安定し、疎結合な状態も保ちやすくなる。 1. 2. 4. CocoaPods廃止 ドメインを丸ごとパッケージ化 XcodeGenの廃止 ● ブランチを切り替えるとXcodeが落ちる。 14
解決できたこと 1. ビルド速度の改善 ● 依存関係が複雑で、1ファイル更新で1,000ファイル以上のビルドが走ることがよくある。 2. チームごとにモジュール担当領域を決め、リードタイムを短縮 ● 機能ごとにチームを分ける想定なので、チームごとに担当するモジュールを決めることで 責務を明確にすることができ、コンフリクトも発生がしづらくなる。 3. 依存関係の解決 ● 影響範囲を最小化することでコード品質が安定し、疎結合な状態も保ちやすくなる。 方針 4. XcodeGenの廃止 1. 新機能はFeatureモジュールを作成 ● ブランチを切り替えるとXcodeが落ちる。 15
02 | これからのマルチモジュール化
Temporaryと負債
現在のChatworkアプリ 📦Features Feature3 Temporaryへ依存したコードは 増え続けている ますます Temporaryの修正が難しくなっている (負債が増えている) 依存 📦Temporary Domain Service Model 18
負債を増やさないための取り組み 「依存関係を解決したもの」に差し替えていくことで Temporaryへの依存をこれ以上増やさない 19
負債を増やさないための取り組み 📦Features 📦Temporary Domain 例えば APIを使って何かを取得する Service.fetch() -> Model Service Model 20
負債を増やさないための取り組み 📦Features HogeFeature 📦Temporary 従来の通りだと Domain HogeService.fetch() -> HogeModel Service Model 21
負債を増やさないための取り組み 📦Features HogeFeature 📦Temporary HogeRepository.fetch() -> HogeModel に切り替える 📦Repository Domain Service Repositoryの実装は Temporaryを利用する Model 22
負債を増やさないための取り組み 📦Features HogeFeature 📦Temporary HogeRepository.fetch() -> HogeModel 📦Repository Temporaryに 依存している Domain Service Model 23
負債を増やさないための取り組み 📦Features HogeFeature 📦Temporary 📦Repository Domain Service Model 📦Entity 依存関係を解決して シンプルな型で切り出し 24
負債を増やさないための取り組み 📦Features HogeFeature 📦Temporary HogeRepository.fetch() -> HogeEntity 📦Repository HogeModel→HogeEntity 変換する Domain Service Model 📦Entity 25
負債を増やさないための取り組み 📦Features HogeFeature 📦Temporary FugaFeature 📦Repository Temporaryに依存する コードがこれ以上 増えない Domain Service Model 📦Entity 26
最後に Tips ● 最短で実利をとるなら、丸ごと外に出すのも有効 ● 嫌な名前にしておくと分割したいモチベーションを保てる ● 共存させることで、負債が増えない状態を作ることができる 27
ご清聴ありがとうございました。 28