読者です 読者をやめる 読者になる 読者になる

Konifar's ZATSU

私はのび太の味方じゃないわ、悪の敵よ

Androidの設計と取捨選択

楽に開発するためにAndroid全体の設計をしたいという思いは、わりとどの開発者も持っている気持ちだと思う。

設計というのは昔から色々揉まれてきて、今はMVPだMVVMだ、DDDだと盛り上がっている。

そもそも、Androidというフレームワークに限定された環境で、わりとよくある実装が多い中で、未だにこれだけたくさんの人が困っているという状態がおかしい。おかしすぎる。そろそろAndroidでこういうの作りたいならこう作るでしょ、みたいなベストプラクティスが確立しているべきじゃないのかという気がする。

あくまで個人的にはだけれども、DataBindingが主流になるのであれば双方向バインディングを使ったMVVMが一番しっくり来る。ただ、MVVMだとViewModelが太ってきてどうすんのみたいなことになるかもしれない。また、通信やキャッシュ部分は別のクラスにわけようとかそういう指針はどちらにしろ必要になる。そのへんまでよくある設計に沿って実装したくなった時にDDDを知ると、なんかDomainの概念とかUsecaseとかRepositoryよさそうと思ってのめり込んでいくかもしれない。

DDDはもちろん悪くない。一般化された役割のクラスに分けておけば、新しく入った人もキャッチアップしやすいし、自分も昔のコードを追いやすい。だけど、DDDというのはいわばめちゃくちゃ複雑なソフトウェアに対する解を体系化したもので、もう色んなケースを想定して作られている。そのため、DDDを実際に適用しはじめてもやっと感じがちなのが「こんな簡単なことやるのにこんなにめんどいことやらないかんの?」ということだ。

これはごもっともな感情で、もういっそActivityに全部書いちゃえばええやろと思うような画面もあったりする。要は、様々なケースを想定した設計を適用しようとした時、その設計が本来Too muchな場所に対してどう判断するのか、という話。例えばそれを例外と捉えてざっと書くというのも1つ。だが、その場合どういう時は設計に準じてどういう時は外れてOKなのかという指針がないと、実装時に考えることが増えてしまう。

設計自体を緩めて、複雑な画面をイレギュラーとして扱うというのも1つ。ただし、その場合も同じようにイレギュラーとはどういうものかという指針が必要になる。

設計を適用するメリットは、将来考えることを減らすことにある。どう作るかの指針が明確で、例外なく全てがそれに準じているのが理想だ。例外が出てきたとしても、例外となる条件が明確になっていれば、新しい機能を作る時に迷う必要がない。迷わなければ実装も速くなるし、ミスも減る。レビューもしやすくいいことづくめである。

Android開発では、できることがたくさんある。そのぶん、設計に組み込む想定を広げておく必要がある。想定を広げれば、Too muchな設計に感じる箇所も増えてくる。それは当たり前のことだ。

個人的には、これは複雑すぎると思った部分は一度削って突き進んで見るといいと思う。例えばDDDで言えば、UsecaseいらんやろRepository直接いじればいいじゃんみたいな時。やってみると、どういうケースを想定して作られた概念だったかわかるときが来る。わからなければ、本当に必要なかったのかもしれない。

いまAndroidの設計の話はネット上にあふれている。けれども、どんな設計でも非同期、キャッシュ、状態管理あたりの指針が決まってればそんなに大変なことにはならないし、実装スピードもそんなに変わらないよなぁと思っている。要は肝心なところだけ指針が揃えてあったらなんでもいい。もちろんこれはAndroidに関して言えば、だけれども。MVVMとかMVPとかいったん忘れてフレームワークのめんどくささに対抗するために工夫してみたら、いつの間にかあれ?これってつまりViewModelでMVVMじゃね?みたいな形に落ち着くと思うし、きっとそれが一番そのプロジェクトに合っているのだと思う。

設計に沿ってクラスたくさん作ることでメモリ食ったりインスタンス生成するコストかかるのが嫌だという人もいると思う。それはそのとおりで、メンテナンスコストとのトレードオフなので難しい。設計を選択する難しさは、アプリの種類やチームの状態によって、様々なこういうジャッジにあるのかもしれない。

色々がーっと吐き出してきたが、バシッと設計がうまくハマった時は最高に気持ちがいいし、ハマる人がハマる気持ちはわかる。ただ設計はもうなんというか、ある程度解のパターンがある中の取捨選択の話であって、パターン自体はGitHubにたくさん上がっているし、わりとお腹いっぱい感ある。取捨選択自体は結局ポリシーの話だからみんな違ってみんないい話だし。

既存のプロジェクトをある設計に揃えることに決めた時にどうしたかという辛そうな話ききたい。作り直すというジャッジだったのかとかパッケージを切って少しずつ移動させていった、とか、途中で例外ケースが出てきた時にどう判断してどうしたかとか、ドキュメントは最初にそろえたかとか、メンバーにアサインするときの進め方とか、初期のレビューのつらみとか、そういう話をね、涙を流しながら聞いてさ、みんなで最高だね最高だねって言って最大限の誠意と感謝を持って労いたい。

ということで、どなたかDroidKaigiでよろしくおねがいします

droidkaigi.github.io