Mirrativ-android-efforts

•Profile •morizooo(@morizo_999) •ミラティブAndroid担当(2018/2〜) •マイブーム:b-monster

Mirrativについて 2.タイトル等設定 3.配信開始 1.起動 Mirrativスマホ1台だけでゲーム実況/ライブ配信を可能にするコミュニケーションサービス

サービスコンセプト＝友達の家でドラクエやってる感じゲームを中心に置いた「コミュニケーション空間」

99 • 5年目アプリの現状 • 課題 • 取り組んでいること今日話すこと

目次 99 アプリの現状

99 Android Gradle Plugin 3.4.0 targetSdkVersion 28 minSdkVersion 16(5月に21に上げる) support
library version 28.0.3 (AndroidX) 言語: Java 8, Kotlin 1.3.30 主要ライブラリ: Koin, Glide, Retrofit, Gson 開発環境

99 アーキテクチャ Activity/Fragment API Client Response (POJO) CustomView (一部だけ) •
いわゆるM-VC

99 ACTIVITY/FRAGMENT Activity/Fragment API Client Response (POJO) CustomView (一部だけ) •
ApiClientを呼び出し結果を Viewに表示 • プレゼンテーションロジックを持つ • View,Controllerの責務を持つ (境目が曖昧)

99 CUSTOMVIEW Activity/Fragment API Client Response (POJO) CustomView (一部だけ) •
Viewのコンポーネントとして切り出された物 • Viewとしての描画の責務を持つ

99 API CLIENT Activity/Fragment API Client Response (POJO) CustomView (一部だけ)
• サーバーに対して問い合わせ行いResponseを取得 • Viewに特化したPOJOを返す

99 feature配下に機能単位にパッケージを切ってUIを配置 → 多数の責務を持ったり、複数のパッケージに依存していたりカオス化... パッケージ構造

目次 99 課題

99 • どこに処理を書くか悩む ◦ パッケージ構造が不明瞭 ◦ ViewとControllerがの境目が曖昧 • 厳密なルールがないのでActivityに処理が集中 ◦
6000行のActivityが存在  責務破綻

99 • マッチョActivityを超える危険なやつら☠☠☠  ◦ 最凶のBaseクラス  ▪ 汎用的に作ろうとしてるせいでたらい回しにされる  ▪ 1000行のクラスを継承する  ◦
ロジックを持ったView  ◦ HelperがViewを持ってる  ◦ checkHogeというメソッドだが副作用がある  責務破綻

99 • 例:オーブ/ダイヤ問題 ◦ 開発当初はダイヤ、リリース前にオーブに変更 ◦ クライアント内ではオーブという名前 ◦ サーバー/分析ログではダイヤという名前のまま ◦
初見殺し爆誕 → アンチパターンとして認識ユビキタス言語がぶれる

目次 99 取り組み

99 O 開発に夢中 KR 2019/4〜に洗い出した辛みを解消し、全platformで理想の状態を確立する全社的に開発体験を見直すときが来た • 週に1日は開発体験向上活動を行う •
各Platformでそれぞれ行われている

99 • 最凶のActivityを倒す • Android Architecture Componentsの導入 • 各層の責務の意識合わせ •
パッケージ構造の整理 • 不要なライブラリの撲滅 • Kotlin化する ANDROIDの取り組み内容

99 • 一番でかいやつを倒せられればなんとかなるだろう理論 • 不要な機能の削除(複雑な仕様を減らす) ◦ ユーザー利用状況踏まえて機能を削除 • Viewに分離 ◦
CustomViewで小さなコンポーネントにしていく • Android Architecture Components の ViewModelの利用 ◦ 状態管理を改善する最凶のACTIVITYを倒す

99 • 公式の設計に役立つライブラリ  • 推奨アーキテクチャとしてMVVMが紹介されている    ANDROID ARCHITECTURE COMPONENTSの導入
https://developer.android.com/jetpack/docs/guide

99 • ViewModel, LiveDataを利用  ◦ Activity<->View間の状態管理が楽になる  ◦ View用のプロパティ置き場として活用(M-VCのまま)  ANDROID ARCHITECTURE
COMPONENTS

99 ANDROID ARCHITECTURE COMPONENTS利用例

99 • Model ◦ クライアントに特化したAPIをサーバーで返しているので、 Responseは基本的にそのまま描画するだけ ◦ iOS/Android/Webでビジネスロジックが各プラットフォームに書かれないようにする ◦
クライアント上にしか存在しないモデルも勿論あるので、そちらはビジネスロジックを持つ各層の責務

99 • View ◦ Viewは情報を表示するだけ ◦ プレゼンテーション/ビジネスロジックを持たない ◦ Modelを直接参照してはだめ各層の責務

99 • Controller ◦ Modelを取得(APIリクエスト実行) ◦ Viewに描画するデータを設定する ◦ Viewのコールバックのハンドリング ◦
一旦Fatにして整理できたら分解する各層の責務

99 天下一パッケージ武道会の結果、機能単位からレイヤー単位にフラットに変える方針にパッケージ構造機能単位レイヤー単位機能+レイヤー？将来的には機能毎に multimodule化する想定

99 • Android Annotations ◦ 昔は便利だったが今ではフレームワークの進化で不要 ◦ 学習コストを掛ける時間がもったいない ◦ 既存コードの意図がわからず解読する時間がかかる
◦ Staticになってテストし辛い部分もあるので消し去る → コードネーム:チョベリバ(死語) 不要なライブラリの撲滅

99 • Java<->Kotlin間の脳内コンテキストスイッチをなくす • 親まで辿ってnullチェックするのがしんどい • 仕様を理解する上で良いタスクになる ◦ 副業で依頼しやすい •
Authorが自分になるので圧倒的当事者意識 KOTLIN化

99 • 現状は苦しいアーキテクチャになっている • GUI/システムアーキテクチャを変更出来る段階ではない ◦ 既存のコードを責務を意識して改善する • 過去のコードに感謝し、スケールできるように改良を続けていく
• 一緒に改善していく仲間を探しています！！！まとめ

Mirrativ-android-efforts

Mirrativ-android-efforts

morizooo

More Decks by morizooo

Other Decks in Programming

Featured

Transcript

Androidアプリの取り組み 2019.04.25 morizooo 突撃隣のアーキテクチャ © 2019 Mirrativ, Inc.

•Profile •morizooo(@morizo_999) •ミラティブAndroid担当(2018/2〜) •マイブーム:b-monster

Mirrativについて 2.タイトル等設定 3.配信開始 1.起動 Mirrativスマホ1台だけでゲーム実況/ライブ配信を可能にするコミュニケーションサービス

サービスコンセプト＝友達の家でドラクエやってる感じゲームを中心に置いた「コミュニケーション空間」

99 • 5年目アプリの現状 • 課題 • 取り組んでいること今日話すこと

目次 99 アプリの現状

99 Android Gradle Plugin 3.4.0 targetSdkVersion 28 minSdkVersion 16(5月に21に上げる) support

99 アーキテクチャ Activity/Fragment API Client Response (POJO) CustomView (一部だけ) •

99 ACTIVITY/FRAGMENT Activity/Fragment API Client Response (POJO) CustomView (一部だけ) •

99 CUSTOMVIEW Activity/Fragment API Client Response (POJO) CustomView (一部だけ) •

99 API CLIENT Activity/Fragment API Client Response (POJO) CustomView (一部だけ)

99 feature配下に機能単位にパッケージを切ってUIを配置 → 多数の責務を持ったり、複数のパッケージに依存していたりカオス化... パッケージ構造

目次 99 課題

99 • どこに処理を書くか悩む ◦ パッケージ構造が不明瞭 ◦ ViewとControllerがの境目が曖昧 • 厳密なルールがないのでActivityに処理が集中 ◦

99 • マッチョActivityを超える危険なやつら☠☠☠  ◦ 最凶のBaseクラス  ▪ 汎用的に作ろうとしてるせいでたらい回しにされる  ▪ 1000行のクラスを継承する  ◦

99 • 例:オーブ/ダイヤ問題 ◦ 開発当初はダイヤ、リリース前にオーブに変更 ◦ クライアント内ではオーブという名前 ◦ サーバー/分析ログではダイヤという名前のまま ◦

目次 99 取り組み

99 O 開発に夢中 KR 2019/4〜に洗い出した辛みを解消し、全platformで理想の状態を確立する全社的に開発体験を見直すときが来た • 週に1日は開発体験向上活動を行う •

99 • 最凶のActivityを倒す • Android Architecture Componentsの導入 • 各層の責務の意識合わせ •

99 • 一番でかいやつを倒せられればなんとかなるだろう理論 • 不要な機能の削除(複雑な仕様を減らす) ◦ ユーザー利用状況踏まえて機能を削除 • Viewに分離 ◦

99 • 公式の設計に役立つライブラリ  • 推奨アーキテクチャとしてMVVMが紹介されている    ANDROID ARCHITECTURE COMPONENTSの導入

99 • ViewModel, LiveDataを利用  ◦ Activity<->View間の状態管理が楽になる  ◦ View用のプロパティ置き場として活用(M-VCのまま)  ANDROID ARCHITECTURE

99 ANDROID ARCHITECTURE COMPONENTS利用例

99 • Model ◦ クライアントに特化したAPIをサーバーで返しているので、 Responseは基本的にそのまま描画するだけ ◦ iOS/Android/Webでビジネスロジックが各プラットフォームに書かれないようにする ◦

99 • View ◦ Viewは情報を表示するだけ ◦ プレゼンテーション/ビジネスロジックを持たない ◦ Modelを直接参照してはだめ各層の責務

99 • Controller ◦ Modelを取得(APIリクエスト実行) ◦ Viewに描画するデータを設定する ◦ Viewのコールバックのハンドリング ◦

99 天下一パッケージ武道会の結果、機能単位からレイヤー単位にフラットに変える方針にパッケージ構造機能単位レイヤー単位機能+レイヤー？将来的には機能毎に multimodule化する想定

99 • Android Annotations ◦ 昔は便利だったが今ではフレームワークの進化で不要 ◦ 学習コストを掛ける時間がもったいない ◦ 既存コードの意図がわからず解読する時間がかかる

99 • Java<->Kotlin間の脳内コンテキストスイッチをなくす • 親まで辿ってnullチェックするのがしんどい • 仕様を理解する上で良いタスクになる ◦ 副業で依頼しやすい •

99 • 現状は苦しいアーキテクチャになっている • GUI/システムアーキテクチャを変更出来る段階ではない ◦ 既存のコードを責務を意識して改善する • 過去のコードに感謝し、スケールできるように改良を続けていく

積極採用中！ © 2019 Mirrativ, Inc.   ◆体験入社/副業制度あります！  改善が好きな方！！！一緒にやりませんか！！！