Mori Atsushi

この記事はPRです。

@mhidakaさんからお声がけ頂き、先日発売された横幕 圭真さんと釘宮 愼之介さんの本「チームで育てるAndroidアプリ設計」をレビューすることになりました。

私なりに読んで感じたこと、そして自分のアーキテクチャの育成に対する考えを書きたいと思います。

PEAKS（ピークス）｜チームで育てるAndroidアプリ設計

読んでみた感想とおすすめしたい人

私は今、2〜4人くらいのAndroidアプリチームのリーダを2年ほど担当しています。

また、JavaからKotlinへ、MVCからMVVM + Layered Architectureのアーキテクチャ移行を絶賛実施中です。

そのため、この本の内容は自分の経験や考えにすごく近いものがあり、共感をしながら読み進めていました。

この本は前半は新規開発の話、後半は大規模開発の話が書かれています。

最新のAndroidアプリのより良いアーキテクチャについて説明されているだけでなく、いかにしてそのアーキテクチャを選択するか、そしてチームに浸透させるか、さらには、その後どうやって進化させていくか、といった話が書かれています。

アーキテクチャの話と言えば、何をどうやって組むかといった実装の話に終始しがちですが、そういったチームの話や運用の話にページが割かれているのが印象的でした。

プログラムは人が書くものなので、アーキテクチャや設計とチームとの関連は切っても切れません。

なかなか文章化しにくい領域でもありますが、かなり丁寧にまとめられており、チーム開発に携わるのであれば予め把握しておくべき内容だと感じました。

近年、Android Architecture Components等のライブラリが整備され、アーキテクチャ関連の記事も充実してきていることから、多くのAndroidアプリ開発でアーキテクチャを意識した開発が増えてきていると感じています。

一方で、目的を理解せずに見様見真似でとりあえず導入しているケースも少なくないと思っています。

本書の中にもありますが、例えばとりあえずMVVMと決めていても、なんのためにそれを採用しているのか理解していなければ、むしろ足手まといになる可能性もあります。

アーキテクチャについて、より一歩深い理解をするためにも、この本をおすすめしたいです。

アーキテクチャの育成について

本書の中でも度々出て来ますが、アーキテクチャや設計を最初に決めても、そのまま開発し続けられるケースは稀です。

何らかの理由により、変更や調整が必要になってきます。

私も新アーキテクチャの設計を固め、移行を開始した後に、以下のような修正を行いました。

• Kotlin Android Extensionsの削除
• Data layerのLiveDataをKotlin Coroutines Flowへ書き換え
• singletonのUseCaseを削除
• SingleLiveEventのDeprecated
• packageやモジュールの整理

以下のような技術は後になって追加しています。

• ViewBinding
• StateFlow / SharedFlow
• 独自scopeのViewModel
• AutoClearedValue
• Feature Flags

こういった変更は、一見どれも良いように見えますが、下手に一部だけ変更を行うと本書にも書いてあるよう、「どれが一番正しい書き方かわからない」といった問題を引き起こします。

それを避けるため、私は以下のようなことを行っています。

1. 導入前にチームに対して相談を行う

チーム全員に画面共有を行いながら、この課題を解決したいため、こう書き換えたい。といった相談を行っています。

変更の規模にもよりますが、実装後のPRでの説明だけでは、不十分だと感じています。

変更の意図と方向性を伝えるのが主目的ですが、そこでより良い解決策が出てくることもあります。

本書の中では、Issueで予め議論することが書かれていました。

議論のログが全て残るという意味では、そちらのほうが好ましいかもしれません。

2. 新しい書き方と、古いコードが古いことがわかるようにする

理想的には全てを一括で新しい書き方に置き換えるべきですが、そううまくいくことはほとんどありません。

そのため、以下の手段を取ることを意識しています。

• ドキュメントを更新する
• 以前のものをlegacy等の名前に変える
• 以前のものにdeprecatedのタグを付ける

とは言ったものの、チームのサイズ的に、全てのPRを私がレビューしており、そこで確認することも多いです。

本書の中では、これらの他に模範となるアーキテクチャを伝えるためのサンプルアプリをつくることが書かれていました。

面白い取り組みだと感じました。

3. リファクタの時間を確保し、統一されていない部分を修正する

古くなった書き方は、放置していても永遠になくなることはありません。

私のチームでは、毎週決まった時間を改善の時間とし、リファクタ等を行っています。

より大きい粒度で異なるアーキテクチャを共存させる方法については、私の書いた「【Android】新旧アーキテクチャが混ざるプロジェクトで気をつけていること」も参考にしてもらえると幸いです。

まとめ

本書の感想から自分のアーキテクチャの育成に対する考え方を紹介しました。

目まぐるしい業界に合わせて、変化をすることは重要ですが、不用意な変更はときに自分たちの首を締めます。

決まったフローで正しく変更することが大事だと感じました。

私は今少人数のチームで開発をしていますが、今回この本を読んで、将来チームが大きくなった際に、今のやり方では上手くいかなくなりそうな点も想像することができました。

前述のような手法で生産性を改善してきましたが、チームのスピードをより高速にするためにも、ドキュメントや変更のフローについて改めて整理していきたいと思います。

PEAKS（ピークス）｜チームで育てるAndroidアプリ設計