はじめに
Android 開発エンジニアを担当している岡田です。
サービスの成長に伴い、コードの肥大化・複雑化は避けられないものだと思います。
しかしながらサービスの成長角度を下げないためには、持続可能で保守性の高いコードを保つ必要があります。
今回は弊社のサービスであるヘルシカにて、上記の問題を改善すべく Android アプリのモジュール化について再検討・実装しましたのでお話しさせていただきます。
ヘルシカについて
ヘルシカは健康的な生活を送るためのヘルスケアアプリです。
この機能を使うことで、食事や体重、体脂肪率を記録できます。
食事の記録ではカロリー計算により健康的な食生活を目指せます。
 |
 |
 |
 |
ヘルシカは以下のリンクからダウンロード可能です！是非、利用してみてください。
モジュール化の利点
モジュール化が話題になって数年が経ちましたが、ここで改めてメリットについて簡単にまとめたいと思います。
以下に自分が特に大きいと感じているメリットを 3 つ選出しました。
アーキテクチャと関心の分離の徹底
アーキテクチャに従って機能や役割ごとにモジュールを分割することで、コードの可読性・保守性が向上します。
モジュール間の依存関係や設計意図をコードレベルで表現できるため、新規参入者にアーキテクチャを共有しやすくなります。
ビルド時間の短縮
モジュールごとに独立してビルドできるため、変更があったモジュールのみを再ビルドすることで、全体のビルド時間を短縮できます。
特に大規模なプロジェクトでは、差分ビルドによる恩恵が大きくなります。
テストの容易性
モジュールごとに独立してテストできるため、ユニットテストや結合テストを効率的に実行できます。
テストカバレッジを向上させ、品質の高いアプリケーションを開発できます。
他にも「コードの再利用性が向上する」、「 チームで開発が分割しやすくなる」などの利点があります。
詳しくは是非、Google Developers の公式ドキュメントを参照ください。
自分の中では「アーキテクチャと関心の分離の徹底」を一番の利点に感じています。
他の利点も重要ですが、コードの構造的な強制力はモジュール化ならではの効果であるためです。
今回はこちらを重要視してモジュール化戦略を再考しました。
ヘルシカ Android アプリ既存のモジュール化戦略
ヘルシカ Android は、既にモジュール化されたプロジェクトでした。
モジュール分割は以下の通りになっており、 各モジュールは、modules というディレクトリ配下に作成されていました。
| モジュール名 | 説明 |
|---|---|
| app | アプリケーションのエントリーポイント。機能に関するコードも保持している |
| api | ネットワーク通信や外部APIとの連携を担う |
| debug | デバッグビルド専用のツールや機能を提供する |
| core | アプリケーション全体で共通して使用される機能やユーティリティを提供する |
| repos | repository の略で、データのリポジトリパターンを実装する |
| resource | アプリケーションで使用する共通のリソースを管理する |
| usecase | アプリケーションのビジネスロジックを実装する |
| widget | 再利用可能なUIコンポーネントを提供する |
| model | アプリ内で使用する共通のモデルクラスを実装 する |
既存のモジュール化戦略の問題点
既存のモジュール化戦略には以下のように、いくつか問題点がありました。
apiやrepos、usecaseに関して、パターン名を命名に使用しているため、アーキテクチャを意識しづらいwidgetやcoreに関して、初見で何が格納されているのか意識しづらいcoreと他モジュールの区分が曖昧- 各機能に関するコードが
app配下に存在しているため、依存関係が曖昧 modulesディレクトリが不要であるreposに関して、略称が使用されており分かりにくい
特に 1 ~ 4 に関して、モジュール化のメリットである「アーキテクチャと関心の分離の徹底」を、十分に享受できていないような戦略になっていることがもったない点でした。
改善後のモジュール化戦略
既存の問題点を改善するためのモジュール化戦略は以下の通りです。
モジュール化戦略を再考するにあたり、Now In Android > Modularization learning journey
を参考にしました。
モジュールの分類
大きな変更点として modules ディレクトリを削除し、すべてのモジュールを core モジュールと feature モジュールの
2種類に分類しました。
ヘルシカでは現時点、機能に関するコードは app モジュール配下に格納されているため、既存のモジュールはすべて core
モジュール配下に移動しました。
| モジュール名 | 説明 |
|---|---|
core |
モジュール間で共有する必要があるコード |
feature |
単一の責任を処理するようにスコープ設定されたコード |
この 2 つのモジュールについては、依存関係が重要です。
coreモジュールは他のモジュールから依存されても良いfeatureモジュール はappモジュール以外からの依存を許さない
依存関係を強制することで、モジュール化のメリットである「アーキテクチャと関心の分離の徹底」を享受できます。
既存モジュールの命名変更
以下の通りにモジュールの命名を変更しました。
| 変更前 | 変更後 |
|---|---|
| api | network |
| repos | data |
| usecase | domain |
| core | common |
| widget | ui |
api、repos、usecaseはパターン名でなく、具体的な役割を示す名前に変更しましたcoreは共通機能を含むことをより明確にするためにcommonに変更しましたwidgetは UI に関連する要素を含むことを示すためにuiに変更しました
命名変更することで、アーキテクチャについて意識しやすくなりました。
また Now In Android とモジュールの命名を似せたため、新規参入者に伝わりやすくなったと思います。
feature モジュールの新設
現時点では app 配下にすべて格納されている状態は、関心の分離の観点から好ましくないです。
従って、単一の機能を持つ feature モジュールを新設しました。
今後は機能ごとに feature モジュール配下へモジュールを作成し、実装を進めていきます。
まとめ
ヘルシカ Android アプリのモジュール化戦略を再考し、以下の改善を実施しました。
- モジュールの分類
- 既存モジュールの命名変更
featureモジュールの新設
これらの改善により、アーキテクチャと関心の分離の徹底を図りました。
現在ヘルシカはこのモジュール化戦略に従い、リファクタリング作業の真っ只中です。
今後も健全かつ人間にとって優しいコードを目指していきたいと思います！
