モバイルアプリケーション開発部の奥澤（@okuzawats）です。月日が経つのは早いもので、Chatworkに入社して既に8ヶ月が経ちました。入社した当時は1歳だった子どもも、今では2歳になりました。この子どもは柿の種が好きで、柿の種を見つけるとすごい勢いで突進してきます。自分は柿の種のわさび味が好きなのですが、柿の種のわさび味は子どもにはちょっと刺激が強いため食べさせられません。そのため、自分が柿の種のわさび味を食べる時は、食べているところを子どもに見つからないように隠れて食べないといけないことが最近の悩みです。皆さんの好きな柿の種は何味でしょうか？
本記事では、自分が入社した昨年2022年9月からこれまでに、Chatwork Android版のライブラリ管理を楽にするために行なった取り組みを紹介します。
現代的なアプリ開発では、ライブラリを利用して開発速度を向上することが必須と言えます。しかしながら、依存するライブラリが増えてくると、その保守に大きなコストがかかってくるようになります。ライブラリの保守を効率的して、より価値のあることに人の力を使えるようにしたい、ということがこの取り組みの意図です。
なお、この取り組みは自分ひとりの取り組みではなく、Androidアプリを開発しているチームでの取り組みであり、チームの成果であることを冒頭に宣言しておきます。
Bill of Materials（BOM）の導入💣
まずは手始めにBOMが使えるライブラリについては、BOMを導入しました。BOMとは、Bill of Materialsの略で、複数のライブラリのバージョンをまとめて管理できるものです。複数のライブラリのバージョンを一箇所で管理できるのでライブラリのバージョン管理が楽になります。また、ライブラリのバージョン差異による意図しない挙動を防ぐのにも役立ちます。ライブラリの保守作業を地味に楽にしてくれる頑張り屋さんです。
Chatwork Android版では、Firebase、OkHttp3、Jetpack ComposeについてBOMを採用しています（画像はJetpack Compose）*1。個々にPull Requestを作成して対応しました。対応いただいたGさん、Oさん、ありがとうございました。
Version Catalogの導入📖
Chatwork Android版では長らく build.gradle にライブラリのバージョンを直接記述していましたが、マルチモジュール化の推進にあたってライブラリのバージョンを集約的に管理したいというモチベーションが生まれてきました。このために取れる方法はいくつか存在しますが、2022年〜2023年の時点ではVersion Catalogを用いる方法がベストであると考えました。
Version Catalogの導入にあたって、ライブラリの更新検知がうまくできるかどうかが課題として挙げられました。この課題については、
- Android StudioがVersion Catalogのサポートを進めていること
- Chatwork AndroidのリポジトリにRenovate（後述）を導入できること
の2点を確認して、解消しました。課題を解消したら、あとはやるだけです。
対応いただいたOさん、そしてレビューいただいたMさん、Gさん、ありがとうございました。
Renovateの導入🤖
Renovateを導入することで、依存関係の更新を自動で検知してPull Requestを作成してくれるようになります。設定次第ではPull Requestのマージまで自動で行うこともできますが、Chatwork Android版では、RenovateにPull Requestを作成してもらうところまでを任せています。Pull Requestのレビュワーがライブラリのリリースノートなどを確認し、コミットを取り込みます。Renovateの設定も試行錯誤しながら改善しているのですが、本記事からは割愛します。いつかその話もしたいですね😼
Renovateについては社内で既に採用実績がありましたので、GitHubの管理者に有効化を依頼するだけでした。
対応いただいたGitHubの管理者の方、そしてRenovateの設定についてレビューいただいたMさん、Gさん、ありがとうございました。
なお、GitHubが提供しているDependabotを採用しなかった理由は「DependabotがVersion Catalogに対応していなかった」ためです。その後、2023年3月にDependabotもVersion Catalogに対応しました🎉
Dependabot version updates keeps Gradle version catalogs up-to-date - The GitHub Blog
ライブラリの削除👻
ライブラリの更新作業が効率的になっても、ライブラリの数が多ければリリースノートの確認などに多くの時間がかかってしまいます。また、ライブラリのsyncにかかる時間も増えるので、開発効率にも影響します。
依存するライブラリの数が多いことで発生する問題は、依存するライブラリを減らすことで解決されます。Chatwork Android版では、この8ヶ月間で17個のライブラリと、2個のGradleプラグインを削除しました。この記事を書いている瞬間も、もっとライブラリを削除するチャンスを虎視眈々と狙っています🐯
削除したライブラリをすべて紹介するのはあまり生産的ではないので、いくつかピックアップして紹介します。
MockitoとMockKを統一する🌍
Chatwork Android版では、テストで用いるモッキングライブラリとして、MockitoとMockKという2つのライブラリを使用していました。
どちらもAndroidアプリ開発で広く用いられているライブラリで、同じ目的を持っています。同じ目的を持ったライブラリが複数存在すると、どちらを使ったらいいか混乱してしまいますし、テストコードを読む時にどちらのライブラリを使用しているのかを気にする必要が出てきてしまいます。そこで、片方のライブラリの使用箇所をもう片方で置き換えて、ひとつに統一することにしました。
MockitoとMockKのどちらを使うべきか？は考え始めると難しい問題です。Chatwork Android版では、MockKを使えば書けるけどMockitoでは書けないテストが存在していました（これについてはまたの機会に...）。そのため、どちらのライブラリを使うべきか？という問題を考えることは回避して、MockKに統一しました。
ユーザー影響のある機能を削除する😢
ユーザーにある機能を提供するために導入されているが、ライブラリが何年もメンテナンスされていない、何ならライブラリのリポジトリがアーカイブされている...というようなライブラリが複数存在しました。単純に置き換えられるライブラリが他に存在したり、我々で実装できる機能であれば大きな問題はないのですが、それが難しいためにそのライブラリが使い続けられています。
こういう場合はエンジニアだけで決めることはできないので、関係各所とコミュニケーションを取り、技術的なコストとリスク、ユーザービリティ、ビジネス的観点、セキュリティなど、総合的な判断をすることになります。ここで多くは語りませんが、いくつかのライブラリについては削除することになりました。ご理解をいただいた関係各所の皆様、ありがとうございました。
いつの間にかいらなくなっていたライブラリを削除する🗑️
KotlinのスタンダードライブラリはKotlin 1.4以降不要となっていましたので、削除しました（What's new in Kotlin 1.4.0 | Kotlin Documentation）。
org.jetbrains.kotlin:kotlin-stdlib-jdk7org.jetbrains.kotlin:kotlin-stdlib-jdk8
諸々の事情でレガシーサポートが切れなかったのですが、気合いを入れて対応してレガシーサポートを削除しました。
androidx.legacy:legacy-support-v4androidx.legacy:legacy-preference-v14
Androidの minSdkVersion を上げていく過程でdesugaringが必要なJavaのAPIへの依存がなくなっていたので、desugar_jdk_libsを削除しました。
com.android.tools:desugar_jdk_libs
こういった「いつの間にかいらなくなる」系のものは、常に目を光らせておかないといけませんね👁️
まとめ
本記事では、Chatwork Android版のライブラリ管理を楽にするために、Androidアプリを開発しているチームが行ってきた以下の取り組みを紹介しました。
- Bill of Materials（BOM）の導入💣
- Version Catalogの導入📖
- Renovateの導入🤖
- ライブラリの削除👻
ライブラリはアプリ開発を楽にしてくれますが、ライブラリの管理自体も楽にできるともっと嬉しいですね。Chatwork Android版を開発するチームでは、本記事で紹介した取り組みの他にも、様々な改善を行っています。Chatwork Android版の本気の改善に挑戦したい！という方はこちらへ💁
*1:この記事を書いている間に、他にもBOMを適用できるライブラリがあることに気がつきました。近いうちに対応します。
