社内のAndroid開発者が集まって、Googleのアプリアーキテクチャガイドを読んだ話
こんにちは、ゆっちです。他社との協業事業として提供しているアプリのAndroid版の開発を担当しています。
また、私は社内のAndroid勉強会を運営しているメンバーの一人でもあります。
どのような勉強会をどういった理由で行なっているかについては、別の運営メンバーが作成した「私がAndroid/iOS 社内勉強会を運営する理由」をご覧ください。
本日は勉強会の一環として、Googleの「アプリアーキテクチャガイド」を社内で読み合わせした際のお話をしたいと思います。
Googleの「アプリアーキテクチャガイド」とは？
Googleが公開しているアプリアーキテクチャガイドのことで、品質の高いアプリを作るためのGoogle推奨のアーキテクチャについて説明されています。
このガイド自体は以前からありましたが、2021年12月に内容が刷新されました。
なぜ読み合わせをしたのか
2021年12月にガイドの内容が刷新されたことで、「最新のおすすめアーキテクチャ」が公式から提示されたことになります。
社内の一部のアプリではすでにこれに近いアーキテクチャを取り込んでいたものの、そのアーキテクチャに理解が追いついていない開発者がいました（私です）。
また、これはあくまでガイドなので、具体的な取り込み方が開発者ごとに微妙に異なっていました。
つまりガイドを社内の開発者が集まって一緒に読むことで、アーキテクチャ自体の勉強と社内の認識合わせができるのではないかと考え、読み合わせの実施に至りました。
どうやって読み合わせしたか
ただ集まって黙々と読むだけでは、理解度に差が出たり、認識がずれたりしてしまいます。
そこでGoogle Jamboardを用いて、「個人の感想」や「他の人に聞きたいこと」を付箋で共有していくことにしました。
またガイドのページ数が多いため、章ごとに読み合わせの会を分け、合計3時間半（30分の会を7回）行いました。
忙しい人も参加できるよう、週に1回という無理のないペースで進め、ガイドを読む黙読の時間も読み合わせの会の中に設けました。
学んだこと
Google Jamboardで共有された付箋を一部抜粋し、社内ではどのような解釈に至ったかを下記にまとめました。
概要
←付箋 社内での解釈→
「ドメインレイヤーはOptionalだけど、
会社で作るアプリ規模的にはあったほうが良い気がする。」
「その理解で良さそう。
UseCaseにロジックを集約するほうが、
ViewModelやRepositoryの見通しが良くなる」
ドメインレイヤー
「UseCaseがUseCaseを持つのに反対ですか？」
「UseCaseからUseCaseを使えるようにすると、
循環参照とかが起きそうで怖い」
「UseCaseがUseCaseを持ちたい時、
命名を変えた方がいいかも。〇〇Managerなど」
データレイヤー
「リポジトリの公開APIは、LiveDataよりもFlowがベターなんですかね？LiveDataでも悪くはない？」
「Repositoryではプラットフォーム固有の実装を無くし、
テストがしやすい設計にできるFlowがよい」
「「追加のロジックが不要な場合は、DAO をリポジトリに直接挿入できることがあります」これは、Datasourceを用意せずに直接Repositoryに持たせてもOKということでしょうか？」
「それであっている。が、あまりオススメしない。
Roomをやめた場合や、他との整合性を考えると
訳がわからなくなりそう」
UIレイヤー
「「UI 自体がそのデータの唯一のソースでない限り」の意味がまだ理解できていない」
「チェックボックスのチェック状態や、
EditTextの中身などのことでは」
「UI状態が複数の関心ごとに分かれている場合、ViewModel（UiState）を複数に分割してもよいのだろうか」
「Fragment in Fragment（またはView）
として切り出せばよいかも。
基本は1Fragment-1ViewModelで、
ViewModelに複数のUI State」
まとめ
読み合わせを通じて、理解が追いついていなかった開発者も不明点を明らかにすることで、新しいアーキテクチャの具体的なイメージを固めることができました。
読み合わせメンバーのうちの1人は、これをきっかけに自身のプロダクトを見直し、DBがボトルネックになりそうなことが分かったためにデータベース移行に踏み切ったそうです。その移行のお話は、先日「SQLiteで運用されてきたAndroidアプリの内部データベースをRoomに置き換えた話」として公開されましたので是非ご覧ください。
また、揃っていなかった認識も、各自の理解を共有し合うことで揃えることができました。
私自身、読み合わせを終えてからプロジェクトを異動しましたが、異動先のプロジェクトでもこのアーキテクチャでアプリが作られていたため、配属３日目には不具合修正のプルリクエストを出せるほど早く理解することができました。
読み合わせは時間がかかる上に優先度が低く、忙しいメンバーがいると「各自読んでね」となってしまいがちですが、集まって読むことで様々なメリットがあります。
1人では十分に理解できるか不安…という方は、ぜひ周りを巻き込んで読み合わせしてみてはいかがでしょうか？