Mirrativ-android-efforts

by morizooo

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

目次 99 アプリの現状

Slide 7

Slide 7 text

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 開発環境

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

目次 99 課題

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

目次 99 取り組み

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

99 ANDROID ARCHITECTURE COMPONENTS利用例

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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