ReluxのAndroidアプリを作り直している話

こんにちは。宿泊予約サービスReluxのAndroidアプリの開発を担当している赤池です。

増築に増築を繰り返してきたAndroidプロジェクトに今時っぽい設計を取り入れていっていますってお話です。同じように「そろそろ設計見直さないとやばいよな、、」って感じている方に少しでも参考になれば幸いです。

なぜ作り直しているのか

ReluxのAndroidアプリは2015年初頭にJavaアプリ化しました。スピード優先でリリースし、その土台の上に機能拡張を繰り返してきた結果、いわゆるマッチョなActivity化がどんどん進行・・・。

ただ、Androidアプリ開発担当は当時からずっと自分一人。ちゃんとした設計がなくても何とかなっていましたが、次第に以下のような問題が顕在化しはじめます。

• どこに何を書くべきかのルールがないので、既存の処理をコードを追って把握しないとならないことが増えたり（自分で書いたのに忘れる）、書き換えるべきコードが点在したりすることで改修コストが大きくなっていく。

• 
機能変更の際などに書き換えるべき箇所が点在しているので、影響範囲の把握漏れでバグを仕込んでしまうことが。

• UIとビジネスロジックが入り組んでいたり特定クラスが肥大化しているので、将来的なチーム開発やテストの導入などが困難。

これらの課題の解決のために設計を見直すことにしました。
また、Javaアプリ化した当時とは違い現在では
設計のベストプラクティス的なものがだいぶ固まってきているので、もはや導入していて当然くらいのレベルになっていることも理由の一つです。

どんな設計を採用したのか

いわゆるMVVMを採用しています。

使っている主なライブラリ

• OkHttp3
• Dagger2
  
- Retrofit2
• RxJava2
• DataBinding

MVVMや各種ライブラリに関しては他の人の素晴らしい記事が色々あるので詳細は割愛させていただきますが、大事なのはレイヤーごとの責務と依存関係を明確に定めることです。定めることでどこに何を書くかが明確になり、ある変更がレイヤーをまたいで問題を起こすことも少なくなり、柔軟で軽リスクの開発ができるからです。

とはいえ、Reluxアプリではこの設計を着くずしている部分もちらほらもあります。ModelにはインフラやRepository層をもうけつつ、UseCaseは冗長になりすぎる感があったのでもうけずViewModelで処理していることなど。

最低限守るルールは守りつつ課題に対して逆効果になりそうな部分は着くずし、個々のプロジェクトの規模や特性にあわせて柔軟に設計するのが良いのかなーと思います。

どのように進めているのか

開発担当一人体制で機能追加などの通常タスクと並行しておこなっているので、合間の時間をうまく捻出して段階的に進めています。そもそも時間をさくのが難しいっていう状況の方もいるかもしれませんが、今のままだとヤバいんですってことをちゃんと伝えて何とかコンセンサスとってください(^^)

一、サンプルアプリで色々試す

既に知見が深い方なら別ですが、設計自体やライブラリに初めての試みが含まれている場合、サンプルアプリを作って一通りちゃんと使ってみることをオススメします。思わぬ挙動にぶち当たったり、一度導入を進めると大きな方針変更がしづらくなるので、本体にいきなり導入だとリスクがあるからです。
自分の場合はタイミングよくReluxMagazineというミニアプリを作るプロジェクトが持ち上がっていたので、その話に乗っかって色々と試しました。

二、モデルを実装し置き換えていく

まずはAPI通信などのインフラ層などを新しくしました。UIに比べて置き換えやすいと思うのでまずはここから着手します。ReluxではDagger2とRxJava2を利用して依存関係を定義/調整しましたが、この段階ではModelとView(Activity/Fragment)がその関係になります。

三、View/ViewModelを実装し置き換えていく

ReluxはUI側の比重が高いアプリなので、ここに一番時間がかかっていて現在も取り組み中です。
DataBindingを導入したのですが、この書き換えは工数がかかります。ListViewだったところをRecyclerViewとObservableListとBindingAdapterを使ってごにょごにょみたいな形に書き換えたりもしているのですが、DataBindingは最低限の利用と割り切ってViewModel側（プログラム）に値のsetなどの処理を書くのも一つかなと思います。

また、モデルの実装でも同じくですが、できるだけ通常タスクで改修する箇所にうまく乗っける形で進めるよう心がけています。そうすることでテストの工数などが多少軽くなるので。

四、最後全体調整

ミニアプリで試して方針決めてから導入を進めましたが、それでも実装を進めていくうちに新たな発見や新しい技術の登場がおこり、やっぱこういう設計の方がよかったかなーという気持ちが湧きあがります。でもそれらを全部適用していくとキリがないので、一旦期限をきっています。
ちなみにReluxはここまでに約一年かかっています。通常タスクをやる人と作り直しをする人がそれぞれいるとベターかと。

おわりに

文章ばかりですみません。。