Photoruction Advent Calendar2021の15日目です。
はじめまして。Androidチームに業務委託としてかかわっている @kgmyshin というものです。
この記事では Photoruction Android アプリのアーキテクチャについて触れていきます。
経緯
PhotoructionのAndroidプロジェクトは、しっかりしたアーキテクチャやルールを設けるタイミングを失ったまま開発を続けてしまっていたため、無秩序気味のコードとなってしまっていました。
そもそも十分に知見がある人を採用できない中でスピードを出さないといけないケースもあるので、これ自体は別に責められるべきことではないです。
ただ結果としてみんなが思い思いのコードを書いてしまう。そして、コードの読解に時間がかかる、修正したいがそもそも影響範囲がめちゃくちゃ広いといったコードになってしまっているため、そこは今後の開発のために対処が必要です。
といった経緯もあり。わりかし知見がある私に「アーキテクチャの方針を決めてもらいたい」というタスクが降ってきたのでした。
ここら辺の現状については、あすの久木田さんの記事でもう少し詳細に書かれると思います。
アーキテクチャの選定のための要素
アーキテクチャ選定に至っては様々な変数があるのですが、その中でもとりわけ大きい変数は以下の二つです。
- 作るアプリの複雑度や規模
- チームの習熟度
作るアプリの複雑度や規模という観点について。Photoruction というアプリは、オフラインでアプリがしっかり動く必要があることと、機能が単純に多いという特徴があります。アーキテクチャは対象のアプリによって適切なものが変わってきます。
下記は アプリにおけるアーキテクチャを示したものではないですし、最近採用されるアーキテクチャではないですが、この図からは、複雑さによって適したアーキテクチャは変わってくるということがわかると思います。
Martin Fowler著： Patterns of Enterprise Application Architecture より引用
肌感ですが。この図に Photoruction アプリを差し込むなら、かなり右の方によるアプリだと感じています。
チームの習熟度について。こちらは現行アプリがレガシーな技術であったり、そもそもアーキテクチャなどが導入されていなかったということもあり、 まだ アーキテクチャなどの精通しているメンバーは多くないというのが現状だと感じています。
まずは秩序だったアーキテクチャがあることに慣れてもらうフェーズ
以上のような要素の中、自分が選択したものは Android Developer サイトにアーキテクチャガイドのアーキテクチャを少しPhotoruction用にかみ砕いたものでした。
このアーキテクチャの特徴は、 ViewModel と Repository があるだけの単純なものです。
Photoruction用にかみ砕いて、実際には次のようなアーキテクチャになっています。
Photoructionアプリは 、先にも述べた通り複雑度が高く規模が大きいアプリです。そのことだけを考慮すると、主観では この Android Developer のアーキテクチャは適していない、というか粒度が大きすぎて足りていない部分があります。
しかし、今回はチームの習熟度という要素を優先して、このアーキテクチャを選びました。
もし、チームの習熟度を無視して、粒度の細かい高難易度のものを選定してしまっても、学習コストが高くて、そこに自分ががっつりコミットする時間がないうえに、もしうまくコードが書けるようになっても、アーキテクチャの細部を理解するまえに「そういうもの」「おまじない」という扱いになりかねなくチームの習熟度への貢献には至らないと考えたためです。（今のところその予定はないですが）自分が抜けてしまっても大丈夫なようにするためには、チームの習熟度を高めることの方が重要なのです。
このアーキテクチャのゴールは「秩序をしっかり作って、秩序に慣れてもらうこと」です。
これが徐々に根付いていけば、例えばルールが決まってないところが出てきて、チーム内でコードの書き方等にブレが出てきた際に、チームでルールを決めようとする振る舞いが散見されるようになります。
まだまだ導入の道半ばですが、実際にそういうケースを見かけることが多くなってきてます。
あと、余談ですが、DIコンテナライブラリ等も使用しておりません。めんどくさいですが、手動で似たようなことを実現してもらっています。手動でやってるので、ゆくゆくは DI コンテナライブラリが何をやっていて、何がうれしいかを知って、導入しましょうという流れになるのかもしれません。
このアーキテクチャだと、まだまだ課題がたくさんあるよね？ってなった時が次のフェーズ
このアーキテクチャだと、まだまだ粒度が大きすぎて課題がたくさんあるよね、と課題を認識できるようになったら次のフェーズです。
では、次はどんなアーキテクチャにするのかについては、特になにも決めておりません。というより自分がすべてを決めるべきではないと感じています。アーキテクチャに沿って開発してきたが、そのアーキテクチャにはいろんな課題があった、じゃあどういうアーキテクチャがいいかをチームで考えてもらって、そこにその時のAndroidアプリ開発事情、チームメンバーの志向を取り入れて、議論する。可能な限り、その際にサポートしようと思っています。
株式会社フォトラクションでは一緒に働く仲間を募集しています。
