拡大期を迎えたプロダクトに 起きたこと - Android編 2022/04/20 @大人気教育アプリ 3社 のモバイルアプリ開発秘話 @yashims85

皆様はどのようなチームで開発を 行っていますか？

私がGlobeeに入社したのは abceedの売上が安定し、規模が 拡大していく最中のことです。

拡大期を迎えたことで、様々な事情 から、再設計を行う必要が出てきた タイミングでした。

Who is me? ● 本名: 屋代昌也 ● 年齢: 36歳くらい ● @ : @yashims85 (やしむす) ● ❤ : スノボ、アニメ、バイク、お酒 ● 2020年末頃にGlobeeに入社し、 Android開発をメインで担当

No content

何を作ってるの？ どうやって発展してきたの？

作っているもの

abceedとは クイズ、シャドーイング、スラッシュリーディングなど 約20種類の豊富なアプリ学習に対応

累計ユーザー数 220万人突破 おかげさまで

なぜ設計を変える必要が出てきた か

なぜ設計を変える必要があったか ● つくった人がずっとコードを追っているので、未知のコー ドが存在しなかった ● 可読性、メンテのしやすさよりも、最短でリリースし収益 化することが優先された ● ミニマムから始め機能を追加していったために、スー パーなんでもクラスが生まれていた

あとから来た人が沼にハマりやすい 環境になっていた。

再設計をするときの注意点

設計を変えるという事が 今までの否定になってはいけない ● 今あるものは作ったときのリソースの制約や、環境のも とで全力で作った結果 ● その当時の設計で拡張できる限界。設計寿命に達した ● だから我々は再設計を行う

既存コードが悪いわけではなく、プロ ダクトに必要とされる価値や優先順 位が変化してきた

実際に変えた設計の一例をご紹介

Fluxアーキテクチャの採用

Flux ● ソフトウェアアーキテクチャの一つ ● MVCやMVVM、Reduxなどと並行概念 ● Redux、Flutter等はFluxの実装系 View Dispatcher Store Action send commit observe create

Flux ● コードの制約度が高い ● 大規模なイベント駆動型ソフトウェア向け ● ボイラープレートが多くなりがち View Dispatcher Store Action send commit observe create 単方向Pub/Sub 参照の向き 呼び出しの順番

なぜFlux？ ● iOS, Androidのエンジニアは相互に補助したり、 p-rを出したり しながら開発を行っている ● そのため何かしらの共通化を行いたい要求がある ● 制約性の高いアーキテクチャで設計を共通化させる。 ○ 制約度が高いと自然と似たようなコードになる ○ それぞれのOS設計上で実装されるので、無理無くできる ● 多人数大規模開発に向いている ● 完全分業ならAndroid標準のMVVMにしたほうが無難な場合 も

AndroidでFlux Fluxは設計概念なので、実装は無数に存在する。 今回は独自で実装したので、それのご紹介です。

AndroidでFlux ● FluxのViewはFragmentに相当 ● Dispatcherは単体だと都合が悪いので、Dispatcherと ビジネスロジックのUseCaseを分離 Fragment (Presenter) Dispatcher UseCase Store Action send commit observe call create

Presenter AndroidでFlux ● FragmentがもりもりになるのでPresenterに分離 Dispatcher UseCase Store Action send commit observe call create Fragment call push ViewModel observe

Presenter AndroidでFlux ● プレゼンテーション層とビジネスロジック層の分離ができた ● ビジネスロジックはプレゼンテーションへの参照を持たない Dispatcher UseCase Store Action send commit observe call create Fragment call push ViewModel observe プレゼンテーション ビジネスロジック

実装 ● Flux Store: reactivex.Observable ● Presenter: FragmentとBLのつなぎ処理 ● Flux Action: メッセージング用data class ● Flux Dispatcher: kotlinx.coroutine ● UseCase: Dispatcherから叩かれ、Storeを更新する処 理

Presenter AndroidでFluxのStore Dispatcher UseCase Store Action send commit observe call create Fragment call push ViewModel observe

Flux Store class UserDetailStore { val error = RxProperty() val userInfo: RxProperty = RxProperty() fun commitError(exception: Exception) { this.error.value = exception } fun commitUserInfo (info: UserInfo) { this.userInfo.value = tabList } } AndroidのLiveDataと同じようなものと思っ て問題ありません。 実装の実態はRx.BehaviourSubjectです。

Presenter AndroidでFluのView Dispatcher UseCase Store Action send commit observe call create Fragment call push ViewModel observe

Flux View (Presenter) class UserDetailPresenter( private val store: UserDetailStore , private val dispatcher: FluxDispatcher , ) { private val disposables = CompositeDisposable() private var vm: UserDetailViewModel? = null // onViewCreated 時などに呼ばれる fun initialize(vm: UserDetailVideoViewModel) { this.vm = vm store.error.asObservable() .subscribe { e: Exception -> vm.postError(e) } .addTo(disposables) store.userInfo.asObservable() .subscribe { info: UserInfo -> vm.postUserName(info. name) } .addTo(disposables) } // onStart 時などに呼ばれる fun showUserDetail (userId: String) { PrepareUserDetailAction( userId = userId).sendTo( dispatcher) } }

Presenter AndroidでFluxのAction Dispatcher UseCase Store Action send commit observe call create Fragment call push ViewModel observe

Flux Action interface FluxAction { fun uid(): String = hashCode().toString() fun sendTo(dispatcher: FluxDispatcher) = dispatcher.dispatch( this) } data class PrepareUserDetailAction( val userId: String ) : FluxAction FluxAction インターフェースを継承することで、後述の FluxDispatcherにいい感じに送れるようにしています。

Presenter AndroidでFluxのDispatcher Dispatcher UseCase Store Action send commit observe call create Fragment call push ViewModel observe

Flux Dispatcher class FluxDispatcher( 　 private val coroutineCxt : CoroutineContext = CoroutineName( "FluxDispatcher" ) + Dispatchers. Default ) { 　 private val observerList : MutableList> = mutableListOf() 　@Suppress ("UNCHECKED_CAST" ) 　 fun register ( 　 klass: KClass< T>, 　 cb: suspend (action: T) -> Unit 　 ): ActionObserver< T> = ActionObserver( 　 klass = klass, 　 cb = cb 　 ).also { 　 runBlocking(coroutineCxt ) { 　 observerList .add(it as ActionObserver) 　 } 　} 　 @Suppress ("UNCHECKED_CAST" ) 　 fun registerOnce ( 　 klass: KClass< T>, 　 cb: suspend (action: T) -> Unit 　 ): ActionObserver< T> = ActionObserver( 　 klass = klass, 　 cb = cb, 　 dispatchCount = 1 　 ).also { 　 runBlocking(coroutineCxt ) { 　 observerList .add(it as ActionObserver) 　 } 　 } 　 fun unRegister (observer: ActionObserver< out FluxAction>) { 　 runBlocking(coroutineCxt ) { 　 observerList .remove(observer) 　 } 　} 　 fun dispatch (action: T) { 　 runBlocking(coroutineCxt ) { 　 val execObserverList = observerList .filter { it.isMyAction(action) } 　 Log.d( 　 "Flux" , 　 "Dispatch action: ${action:: class.simpleName }#${action.uid() } for ${execObserverList. size} observers." 　) 　 execObserverList. forEach { observer: ActionObserver -> 　 CoroutineScope(Dispatchers. Default ).launch { 　 observer.observe(action) 　 withContext( coroutineContext ) { 　 if (observer. dispatchCount > 0) { 　 observer. dispatchCount -- 　 if (observer. dispatchCount == 0) { 　 unRegister(observer) 　 } 　 } 　 } 　 } 　 } 　 } 　 } 　 companion object { 　 private const val DISPATCH_UNLIMITED : Int = - 1 　} 　 data class ActionObserver< T : FluxAction>( 　 val klass: KClass< T>, 　 val cb: suspend (action: T) -> Unit , 　 var dispatchCount : Int = DISPATCH_UNLIMITED 　 ) { 　 fun isMyAction (action: T): Boolean = klass.isSuperclassOf(action:: class) 　 suspend fun observe (action: T) = cb.invoke(action) 　 } } 資料は公開する予定です ので、後ほどご確認くださ い！

UseCase // data class PrepareUserDetailAction ( // val userId: String // ) : FluxAction class UserDetailUseCase( private val dispatcher: FluxDispatcher , private val userRep: UserRepository , private val store: UserDetailStore , ) { private val disposables = CompositeDisposable() init { dispatcher.register(PrepareUserDetailAction:: class) { prepareUserDetail( it.userId) } } private fun prepareUserDetail (userId: String) { userRep.readUserInfo(config) .subscribe({ userInfo: UserInfo -> store.commitUserInfo(userInfo) }, {e: Throwable -> store.commitError(e as Exception) }) .addTo(disposables) } } Dispatcherに登録。 callbackは、バックエン ドスレッド内で実行され てる NWエラー等が発生し てもエラーの正常系と して扱える！ バックエンドからデータ を取得しStoreに commit

Fluxイベントサイクル プレゼンテーションイベントサイクル Presenter AndroidでFlux プレゼンテーションイベントサイクルと Fluxのイベントサイクルが分離さ れ、Presenterで接続されている Dispatcher UseCase Store Action send commit observe call create Fragment call push ViewModel observe 参照の向き 呼び出しの順番 赤字 非同期

まとめ ● プロジェクトや組織のフェーズによって、コードに求めら れる優先価値は変わってくる ● プロダクトは組織や顧客の写し鏡 ○ ある設計やその設計を元にしたコードには寿命が 存在する ○ 課題が変化したタイミングが再設計の良いタイミン グ ● Fluxの単方向Pub/Subは多人数開発ではとても具合が 良いので、同じような境遇の方はネタの一つに加えてみ てはいかがでしょうか？

Eigo wakaran!! Globeeでは一緒に働いていただける エンジニア募集中です！ (英語ができなくても大丈夫です！)

おわり