Chatworkアプリのマルチモジュール戦略

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