熟成されたアプリのmulti module化(halfway)

Transcript

1. 熟成されたアプリの multi module化(halfway) Shibuya.apk #33
2. 自己紹介 • Android, Embedded system, BLE, iOS • DeNA Co., Ltd. Automotive Business Unit. • 最近、少し高めのカメラレンズ（約8.5万円）を購入 tomoya0x00 Twitter, GitHub, Qiita
3. 比較的、泥臭い話をします
4. その中で皆様にとって 有益な情報があれば嬉しいです
5. アウトライン 熟成されたアプリとは？ なぜmulti module化するのか？ 最初のmodule分割 残りをmodule分割 1 4 3 2
6. 熟成されたアプリとは？
7. 熟成されたアプリと名乗るには 『必要な要素』 だと思ったモノに、 手を上げてください
8. クラスの循環参照が発生 ※Daggerのlazyで無理矢理コンパイルを通している
9. 状態をあわらすフラグが多数存在
10. Rxの乱用で 処理を追うのが困難
11. Singletonかつ、 mutableなクラスが多数存在
12. レイヤーを無視した クラス間の参照
13. 複数のアーキテクチャが混在
14. パッケージのトップに 色々なファイルが置いてある
15. 複数の神クラスが存在 ※神クラス ＝ 巨大かつ様々なクラスに依存されている
16. WebAPIのレスポンスを そのままいたるところで使いまわす ※なお、全てのプロパティがnullable
17. 安心して下さい
18. 今回お話しする 「熟成されたアプリ」は
19. 全ての要素を満たしています！！
20. 話を続けましょう
21. なぜmulti module化するのか？
22. 理由１ 機能ごとのlibrary moduleに分割し、 新規アプリで使いたい
23. 理由２ library module間の依存関係を強制し クラス間の循環参照を撲滅したい
24. 最初のmodule分割
25. 準備
26. 準備 1. 参考資料・ソースに目を通す 2. 切り出したい機能と、 仮のmodule名を一覧化する 3. ブランチかフォークか決める
27. 参考資料・ソースに目を通す ～ その1 ～ • kgmyshinさんの マルチモジュールのすヽめ と 大きめのAndroidアプリでの 設計を考えてみる~pocket~ • レイヤーによるmodule分割と、 機能によるmodule分割
28. 参考資料・ソースに目を通すす ～ その2 ～ • クックパッドアプリの マルチモジュール化への取り組み • 既存の全ての機能を legacy library moduleに移動 • DroidKaigi/conference-app-2019 • 機能ごと（画面も含めて）にlibrary moduleを分割 • interfaceだけのmoduleと、実装のmoduleに分割
29. 切り出したい機能と、仮のmodule名を一覧化する • 分析ログ • analytics-log • BLE通信 • ble • 位置情報 • location etc...
30. ブランチかフォークか決める ～ ブランチの場合 ～ • 既存リポジトリでブランチを切って作業 • かなり変更量大のプルリクをつくる事になる • 既存の熟成されたアプリへの影響大 • 途中でdevelopブランチへのマージは厳しい • フルのリグレッションテストを何回も実施？？
31. ブランチかフォークか決める ～ フォークの場合 ～ • 既存リポジトリをコピーした 別リポジトリで作業 • 既存リポジトリへの影響無しに作業できる • ただし、どこかのタイミングで 既存リポジトリの差分マージが必要
32. ブランチかフォークか決める ～ 結論 ～ • フォークしてモジュール分割を進め、 新規アプリ開発を優先 • モジュール分割が落ち着いたら 既存リポジトリの差分をマージ • いずれ既存アプリも、 フォークした別リポジトリからリリース
33. まずは一つ moduleを分割して 様子をみる
34. 今後のmodule分割作業の 見積もり精度が上がる
35. どの機能をmodule分割するか？
36. 自分がほとんど書いた機能 （BLE通信周り） ならば、難易度が低いと判断
37. 自分が知っている機能なら 楽勝でしょ？
38. 考えが甘かった （結構大変だった）
39. 一週間ぐらいかかった
40. 最初のmodule分割で やって良かったことや学びなど
41. 最初のmodule分割でやって良かったことや学びなど • Dep.ktとVersions.ktの導入 • 具体的なmodule分割の手順 • Android Studio様は強い味方 • 細かいTips • ディレクトリ、BuildConfig、ProductFlavor • Dagger周り
42. Dep.ktとVersions.ktの導入
43. Dep.ktとVersions.ktの導入 multi module化すると 各library moduleにbuild.gradleがあるため、 指定するバージョンなどがバラバラになる危険性 Kotlinで各dependenciesやバージョンを記入し、 各build.gradleで使用する 参考： DroidKaigi/conference-app-2019のdependenciesディレクトリ Kotlin + buildSrc for Better Gradle Dependency Management
44. Dep.ktとVersions.ktの導入 ～ Dep.kt ～ Dep.kt: 各dependenciesを記入 object Moshi { private val version = "1.8.0" val moshi = "com.squareup.moshi:moshi-kotlin:$version" val codegen = "com.squareup.moshi:moshi-kotlin-codegen:$version" }
45. Dep.ktとVersions.ktの導入 ～ Versions.kt ～ Versions.kt: compileSdkVersionやversionCode（※ソースでは省略）などを記入 object Versions { const val androidCompileSdkVersion = 28 const val androidMinSdkVersion = 23 const val androidTargetSdkVersion = 28 }
46. 具体的なmodule分割の手順
47. 具体的なmodule分割の手順 ～ module新規追加 ～
48. 具体的なmodule分割の手順 ～ module新規追加 ～
49. 具体的なmodule分割の手順 ～ module新規追加 ～
50. 具体的なmodule分割の手順 ～ module新規追加 ～
51. 具体的なmodule分割の手順 ～ module新規追加 ～
52. 具体的なmodule分割の手順 ～ module新規追加 ～
53. 名前にハイフンが入っているとダメ →後からリネームならOK
54. 具体的なmodule分割の手順 ～ module新規追加 ～
55. 具体的なmodule分割の手順 ～ module新規追加 ～
56. 具体的なmodule分割作業の手順 ～ build.gradle編集 ～ • library moduleのbuild.gradle編集 • DroidKaigi/conference-app-2019の android.gradleを参考に、 library moduleで共通してapplyするBuild Script導入がお勧め • 各dependenciesの記入 • app moduleや、必要に応じて既存のlibrary moduleのdependenciesに追加
57. 具体的なmodule分割作業の手順 ～ クラスの移動 ～
58. 具体的なmodule分割作業の手順 ～ クラスの移動 ～
59. 具体的なmodule分割作業の手順 ～ クラスの移動 ～
60. 意外と楽ちん！？
61. 具体的なmodule分割作業の手順 ～ クラスの移動 ～
62. 具体的なmodule分割作業の手順 ～ クラスの移動 ～ • 参照できないクラスが色々あって怒られてる • Retrofit周り • library moduleのbuild.gradleに追加 • API Responseのclass • app moduleにあるので参照できない • library moduleへ同時に移動する
63. より効率良くおこなうならば？
64. 具体的なmodule分割作業の手順 ～ クラスの移動 ～ 1. 移動するクラスの依存先をリストアップ a. import文でわかる 2. Retrofitなどlibraryはbuild.gradleに追加 3. アプリ内部のクラスであれば同時に移動 a. 単純に移動できない場合は、interface抽出して 一旦依存性を切り離すなど
65. Android Studio様は強い味方
66. Android Studio様は強い味方 ～ 強力なリファクタリング機能 ～ • クラスを別moduleへ移動 • 「具体的なmodule分割作業の手順」で紹介済み • interface抽出 • クラスからPublicなプロパティ、メソッドを選択してinterface 抽出 • ネストされたクラスの移動 • 抽出したinterfaceが、実装クラスにネストされた Enumクラスに依存している場合などに便利
67. Android Studio様は強い味方 ～ interface抽出 ～
68. Android Studio様は強い味方 ～ interface抽出 ～
69. Android Studio様は強い味方 ～ interface抽出 ～
70. Android Studio様は強い味方 ～ ネストされたクラスの移動 ～
71. Android Studio様は強い味方 ～ ネストされたクラスの移動 ～
72. Android Studio様は強い味方 ～ ネストされたクラスの移動 ～
73. 細かいTips • 階層化にディレクトリを使うか否か • library module で BuildConfig を参照 • Product Flavorとリファクタリング
74. 細かいTips ～ 階層化にディレクトリを使うか否か ～
75. 細かいTips ～ 階層化にディレクトリを使うか否か ～
76. Android View だとディレクトリ無視 →moduleがフラットに名前順で並ぶ
77. 気になる場合は ディレクトリでは無く module名の接頭語で階層化
78. 細かいTips ～ 階層化にディレクトリを使うか否か ～
79. 細かいTips ～ library module で BuildConfig を参照 ～ • BuildConfigから参照したいプロパティの interfaceを作成 • library moduleは上記のinterfaceに依存 • app moduleで実装をlibrary moduleに注入
80. 細かいTips ～ library module で BuildConfig を参照 ～ interface EnvVar { val BUILD_TYPE: String val API_HOST: String } object EnvVarImpl : EnvVar { override val BUILD_TYPE = BuildConfig.BUILD_TYPE override val API_HOST= BuildConfig.API_HOST }
81. 細かいTips ～ Product Flavorとリファクタリング ～ Product Flavorでソース切替している場合 現在のFlavor以外はリファクタリング対象外
82. Dagger周り DroidKaigi/conference-app-2019 を参考に library moduleごとに ModuleとComponentを作成
83. 残りをmodule分割
84. ふむふむ、やり方はわかった
85. 色々踏み抜いたし残りは楽勝っしょ！
86. module分割を続行･･･
87. できない
88. 元々の依存関係がぐちゃぐちゃで interfaceの実装クラスを 各moduleに切り出せない･･･
89. interface抽出して 依存関係を逆転させても 実装自体の依存関係が 逆転するわけではない
90. どうするのか？
91. 正攻法で立ち向かう
92. 何が依存関係を複雑にしているのか？
93. 何が依存関係を複雑にしているのか？ • APIレスポンスを保持して提供する 神クラスが複数存在 ◦ ビジネスロジックも持っている • 分析ログ機能 ◦ 複数の神クラスに依存
94. 2種類のリポジトリを導入
95. WebApiをラップするRepository • レスポンスをmodelに変換して Observableで提供 • データ更新の関数は結果を返さず、 更新のトリガーとするだけ
96. 神クラス公開情報を保存し、提供するRepository • 神クラスのみが書き込む • 神クラス以外は読み込みオンリー • これで神クラスへの直接依存を防げる
97. module分割が続行可能となった
98. 迷っているところ
99. multi moduleでのDagger周りの 話しを皆様から聞きたい！！
100. ありがとうございました