Androidアプリのモジュール分割における:x:commonを考える

Androidアプリのモジュール分割における:x:commonを考える 2024/12/20 Ebisu.mobile #8 大忘年会 STORES kubell Kyash asken
/ 奥澤俊樹

自己紹介奥澤俊樹（@okuzawats） Androidアプリエンジニア / 株式会社kubell ビジネスチャット「Chatwork」 Android版アプリを作っています。来年は前厄です。

事業概要 *1 Nielsen NetView 及びNielsen Mobile NetView Customized Report 2024年4月度調べ月次利用者（MAU:Monthly
Active User）調査。調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む41サービスを株式会社kubellにて選定。 *2 2024年9月末時点。 • 国内最大級のビジネスチャット「Chatwork」を展開。業界のパイオニアであり国内利用者数No.1*1、導入社数は60.5万社*2を突破 • 圧倒的な顧客基盤とプラットフォームを背景に、DXされた業務プロセスそのものを提供するクラウドサービス、BPaaSを展開 BPaaS (Business Process as a Service) ビジネスチャット「Chatwork」お客様オペレーター

「Chatwork」Android版アプリ

モジュール分割サービスの拡大と、メンバー・チームの増加に伴い、モジュール分割の必要性が高まってきました。まだ途上ではありますが、去年（2023年）からモジュール分割を進めています。モジュール分割の狙いは、アプリの規模（コードのサイズ、メンバーやチームの数）が大きくなっても開発速度を維持していくこと、将来の予測できない変化にすばやく対応できる能力を持つことです。具体的には、以下のようなメリットを期待しています。 - 関心の分離と依存方向の強制（目指すアーキテクチャの実現） -
モジュールごとのビルドキャッシュを利用したビルド高速化 - コンフリクト発生頻度低減による開発速度の維持 - などなど

モジュール分割大まかには、以下のような方針でモジュール分割を進めています。

モジュール分割レイヤごとにモジュール化し、さらにサブモジュールを作ることもあります。

モジュール分割 :featureモジュールには、View・ViewModelなどプレゼンテーションに関するコードが存在します。

モジュール分割今日は、この中でも特に:commonモジュールについて考えてみます。

:x:common

:x:commonとは :xの各サブモジュールから参照される、各サブモジュールの共通コードの置き場となるモジュールを指す。 :x:commonもまた:xのサブモジュールであるが、他のサブモジュールから参照される特別なサブモジュール。

:x:commonとはきちんと考えないと多くのコードがcommonモジュールに置かれてしまい、本来モジュール分割から得られたはずのメリットが得られなくなる可能性がある。 - :x:commonの修正は影響範囲が大きく、影響の確認に手間がかかる。 - 他チームの作ったモジュールに影響すると、コミュニケーションコストが増える。 - その結果、メンバー・チームが増えた時の開発速度低下につながる可能性がある。

:x:commonとは「Chatwork」Android版では、モジュール分割の過程で:feature:commonモジュールが大きくなってきました。本発表では、 - :x:commonモジュールを小さく保つためにどうすればいいのか - 大きくなった:x:commonモジュールを小さくするためにどうすればいいのかという2つの観点で、考えたこと・実践したことを話します。

:x:commonモジュールを小さく保つ

:x:commonモジュールにコードを書かなければ、:x:commonモジュールは小さいまま。そのためには、以下のことを考えるのが良いと思う。 - コードの重複を恐れない - サブモジュールの分割単位を考え直す :x:commonモジュールを小さく保つ

- :x:commonに共通コードを置き、共通コードを:xの各サブモジュールが参照している場合、複数のサブモジュールに対して同時に変更が影響する。 - 共通コードを使用しているすべての箇所に、共通コードの変更が影響する。 - 共通コードの変更が各サブモジュールに影響することが嬉しいか、嬉しくないかを考える。嬉しくないなら、コードの重複（コピペ）を許容した方がいいかもしれない。 -
コードの重複と引き換えに、開発速度を得られる可能性がある。コードの重複を恐れない

- :x:commonに置いた共通コードが特定の複数のモジュールからのみ参照されていて、かつ常にそれらのモジュールへ同時に変更を適用したいのであれば、それらのモジュールはひとつのモジュールであるべきなのかもしれない。 - 本来、ひとつのモジュール内で結合しているべきコードなのかもしれない。 - そうであれば、分割したモジュールをあえて統合すべきかもしれない。サブモジュールの分割単位を考え直す

例えば、画面Aと画面Bで同じに見える部品が使われていたとする。 :x:commonモジュールを小さく保つ：具体例画面A 画面B

これらが違うように変更されていくなら、それぞれのモジュールにコードをコピペした方が開発速度が出るかもしれない。 :x:commonモジュールを小さく保つ：具体例画面A 画面B

これらが同じように変更されていくなら、そもそもこれらの画面を同じモジュールに入れるべきなのかもしれない。 :x:commonモジュールを小さく保つ：具体例画面A 画面B

大きくなった:commonモジュールを小さくする

単に:x:common:sub-1、:x:common:sub-2、...と増やしていくという話ではない。依存関係の組み合わせを考えることは避けたいし、commonモジュールを使う側がいちいち依存関係を考えないといけないのではcommonモジュールの意味がない。大きくなった:x:commonモジュールを小さくする

:x:commonモジュールを必要としているモジュールが本当に必要なのは、:x:commonモジュールの持つ抽象のはず。大きくなった:x:commonモジュールを小さくする

モジュール単位で依存関係逆転原則を適用して、モジュール間の依存関係の向きを制御できる。:x:commonの具象をサブモジュールに移して、具象と抽象を切り離すことができる。大きくなった:x:commonモジュールを小さくする

:xモジュールの各サブモジュールからは、:x:commonモジュールのみを参照すれば良い。綺麗なモジュール間の依存関係が手に入る。大きくなった:x:commonモジュールを小さくする

あくまで「:x:commonモジュールが大きくなってきた時に使えるかもしれない」程度の方針。 :x:commonをサブモジュールに分けなくて済むのであれば、分けなくて良い。大きくなった:x:commonモジュールを小さくする

まとめ

- アプリの規模（コードのサイズ、メンバーやチームの数）が大きくなるに従って、アプリのモジュール分割から大きなメリットが得られるようになる。 - モジュールをさらにサブモジュールに分ける時、共通コードを置くためのモジュールが必要になる場合がある。 - :xモジュールの共通コードの置き場となる:x:commonモジュールが大きくなると、モジュール分割から得られるはずのメリットが得られなくなる可能性がある。 -
:x:commonモジュールを小さく保つ。 - コードの重複を恐れない。 - サブモジュールの分割単位を考え直す。 - 依存関係逆転原則を用いて、:x:commonをサブモジュールに分割できる場合もある。 - 分割しないで済むなら分割しなくて良い。まとめ

Androidアプリのモジュール分割における:x:commonを考える

Androidアプリのモジュール分割における:x:commonを考える

okuzawats

Transcript