Mobility Technologies Co., Ltd. タクシーアプリ「GO」の 巨大化による課題と解決の道を探る 2022/8/10 Byungjun, Park

Mobility Technologies Co., Ltd. 2 パク ビョンジュン(Byungjun, Park) 出身地 : 韓国(大邱) 現在: 横浜 iOSエンジニアとして 2015~2019 Fintech系サービス開発 2019~ Mobility Technologies Side project: React native 趣味: サイクリング・ランニング、旅行、レトロ ゲーム 自己紹介

Mobility Technologies Co., Ltd. 2020年、統合直後の当時のiOSエンジニア数 MOV 4人、JapanTaxi 4人 => 合計8人体制 => ということはもしかして開発速度2倍(?) 開発チームのスケールアップ 3

Mobility Technologies Co., Ltd. ・「JapanTaxi」アプリをクローズするための開発 ・コードベースがMOVなので「JapanTaxi」アプリを開発してたメンバーのプロダクト理解度 ・サーバ仕様も新しい ・モビリティサービスならではのデバック環境の難易度(feat. 乗務員端末・タブレット) リソースも増えたが、やりたいことも増大 4

Mobility Technologies Co., Ltd. 2020年9月「GO」をリリースとビジネスとしての新機能開発 進むサービスの巨大化 5

Mobility Technologies Co., Ltd. サービスの巨大化に伴う課題 6

Mobility Technologies Co., Ltd. 開発スピードを高速化するための項目 7 アーキテクチャ変更

Mobility Technologies Co., Ltd. MVVMからRIBsアーキテクチャーの導入 チームとサービス規模のスケールに耐えるため 8

Mobility Technologies Co., Ltd. ■ ルーティングの細分化 ■ SPAに近いUIなので、コンポーネントで分割して利用できる ■ テスタビリティの向上 ■ Interactorにすべてのビジネスロジックがあるので、Unit Testがしやすい ■ DIが容易 ■ 複雑度の高い箇所のリファクタリング ■ MVVMなどはView単位のコンポーネント分解になるが、RIBsはロジック単位でコン ポーネント分解できるため、細かくコンポーネント分解ができる ■ 責務の明確化、実装の統一化 ■ ロジック単位で分割できるため、責務を明確化することができる。 RIBsを選んだ理由 9

Mobility Technologies Co., Ltd. 起動後 => 配車依頼まで 279個のコンポーネント 導入後のタクシーアプリ「GO」 10 RIBsのコンポーネントツリーの構造図 （2022年8月現在） =>

Mobility Technologies Co., Ltd. 11 Targetのコンパイルソースが500 -> 2200以上に増加 増大するファイル数とそれに伴うビルド速度の増大 ■ 気軽なTrial and Error開発に難しい ■ CIも遅い ビルド時間の増加

Mobility Technologies Co., Ltd. ■ クリーンビルドを高速化 ■ PodBuilder(https://github.com/Subito-it/PodBuilder)を導入して、CocoaPodsのバ イナリーをキャッシュする ※ CocoaPodsのFrameworkをprebuildし保持させxcodebuild時にビルド済みのを 利用させる => 導入済み ■ 差分ビルドを高速化 ■ マルチモジュール => 現在進行系 ビルド時間の増加の問題に対する解決策 12

Mobility Technologies Co., Ltd. マルチモジュール化 STEP1 - Doing 13 GO App Core GOUIKit Utility Resources APIClient 共通View component Repository, Model SwiftUI/UIView

Mobility Technologies Co., Ltd. Feature3 マルチモジュール化 STEP2 - Todo 14 GO App Core GOUIKit Utility Resources Feature1 LoggedIn GOPay History LoggedOut Feature単位でのモジュール定義と開発 Feature2

Mobility Technologies Co., Ltd. マルチモジュール化の進め方 15 モジュール分割 モジュール定義の整理が必要になる モジュール間の循環参照の考慮が必要になる

Mobility Technologies Co., Ltd. モジュール間の依存が複雑になるため、XcodeGenのyml管理だと、ビルドするまでエ ラーを検知できないので、Project・Targetの依存関係など設定が辛い マルチモジュール化を進めていくにあたっての課題 16 Tuistの導入を検討する

Mobility Technologies Co., Ltd. Tuistとは 17 project.ymlではなくProject.swift XcodeGenのようにproject生成道具 ・XcodeGenのようコマンドラインで xcodeprojを作ってmerge 時のconflictを回避 ・設定が簡単 ・再利用性が高い ・プロジェクトキャッシング ・依存関係のビジュアル化 https://tuist.io/ ・最大のメリットはswift言語によるproject設定の定義

Mobility Technologies Co., Ltd. Tuist 18 Project.swift Workspace.swift Dependencies.swift

Mobility Technologies Co., Ltd. Tuist 19 ・強力な入力補完でミスのストレスから解放 ・重複設定をfunction化したり(XcodeGenもTemplateはある) ・必要なモジュールの組み合わせで複数のworkspaceを作ることが期待できる。

Mobility Technologies Co., Ltd. XcodeGen vs Tuist 20 ・一番使われてる道具なので問題が起きた時の対 策がある可能性が高い ・キャッシュ機能が弱い ・yml… ・Swiftで書く、読む ・Targetキャッシュ機能が豊富 ・そもそもの設定項目が多い ・まだ利用事例が少ない

Mobility Technologies Co., Ltd. tuist graph：tuistで定義したマルチモジュールの依存関係を図示してくれる Tuistでの更に便利な機能 21

Mobility Technologies Co., Ltd. ・チーム内での課題の十分に共有 ・課題解決へのモチベーション ・いきなり難易度高い課題を一気に解決するよりステップアップ ・重要度が低い機能は積極的に削除 ・道具を利用する(できれば) おわりに 22 アプリの巨大化による技術的な課題に向かって

Mobility Technologies Co., Ltd. Appendix 23 03

Mobility Technologies Co., Ltd. iOSDC 2021 大規模リファクタリングの極意 https://fortee.jp/iosdc-japan-2021/proposal/589c4329-022b-47c9-b8ea-b913eacf831b RIBs アーキテクチャにおける木構造の再構築について https://lab.mo-t.com/blog/ribs-workflow iOS アプリにおけるアーキテクチャの部分適用について https://lab.mo-t.com/blog/ribs-in-part iOS アプリを木構造で組み立てるための 7 つのデザインパターン https://lab.mo-t.com/blog/ribs-architecture-design-patterns iOSアプリでビジネスロジックの肥大化を回避するコツ！ https://lab.mo-t.com/blog/ios-tips-logic-bloat GOのRIBsアーキテクチャ採用とリファクタリング 24

Mobility Technologies Co., Ltd. Storyboardベースのレイアウトを徐々にコード化(EasyPeasyで記述、最近はSwiftUIも少し ずつ) チームとサービス規模のスケールに耐えるため 25

文章·画像等の内容の無断転載及び複製等の行為はご遠慮ください。 Mobility Technologies Co., Ltd. 26