chigichan24のお気持ち表明

おきもちを表明している

DroidKaigi2020での発表スライドの補足と雑記

はじめに

本当に残念なことに，DroidKaigi2020は中止となってしまいました．とても残念でしたが昨今の事情を考えればこの判断は適切なものだったと思います．

medium.com

さて，DroidKaigi2020は中止となってしまったが，せっかく作りかけていた資料だし作りきって公開しようと思います．

もともと私のセッションはJA・EN(同時通訳)対象のものになっており，スライドは英語のものが求められておりますが，一旦は日本語のものだけを公開します英訳が本当に進みませんでしたごめんなさい．もうちょっと時間をかけてゆっくり英訳します．

このブログではスライドだけでは伝わらないかもしれない細かい部分の補足を前半に，後半は僕とDroidKaigiの雑談を書いていこうと思います．

スライド

speakerdeck.com

内容補足

以下の補足内容を先に読んでからスライドの方を見る，あるいは並行しながら見ると分かりやすいかと思います．

背景

このスライドは Wantedly, Inc. さんでのインターンシップでの経験をもとに作成しました．実際に私がマルチモジュール化を進めている裏で機能開発/改善は進められており，どういうふうに進めればこの2つは共存できるのだろうという疑問からこの内容で発表することにしました．

単にモジュールを切り分ければ良い，Dagger2でいい感じに配れば良いというような玄人向けではなく，自分自身やってみたけどうまくいかなかったことや断片的には資料はあるがまとまって一つの資料となっていないという問題を解決したいという思いもありました．そのため，本質的にはマルチモジュール化とは関連無いが周辺知識としては必要だよね🤓🤓という内容も盛り込んでいます．

内容の具体性

全体的に薄く広く書くことを意識しました．具体性の高いソースコードを多用するよりもテクニックとしてこのようなものがあるよ！こういうものは手段として有効だよという方針で全体を通して書き進めています． こうしたのにはいくつかの理由があります．

  • 個別すぎる事例はプロダクトの性質やチームの方針によって変わるものだと考えているから
  • 具体的すぎるコードは共感を呼びにくいから(抽象度が高いと各事例に応用しやすいと考えたから)

例えば，どんな基準でモジュール分けを行うのがいいのかという内容等は省く決断をしました．これはプロダクトの性質や当然チームの方針で粒度が変化するものだと思っているからです．

読者のターゲット

  • アプリのモジュール化に興味がある人
  • モジュール化の「手順」に興味がある人
  • 継続的に機能開発・改善を進めながらモジュール化することに興味がある人

これらの人々に対して，「抽象的すぎてなにを言いたいのかわからないと，具体的すぎてうちの事例には当てはまることがなさそうの中間」を狙って書きました．スライドで示したことを全て用いるということは無いと思いますが，部分部分そのエッセンスを取り入れていただけたら嬉しいです．

第0章 (pp. 1 - 12)

第0章 はOutlineの紹介です．加えて，各章の関係性を示しています．1章はモジュール化導入の価値について，2章から5章までが私が設定したトピックごとのモジュール化に関するテクニックについてで，6章がまとめの章のような流れとなっています．

第1章 (pp. 13 - 37)

第1章はモジュール化導入の価値について語っている章です．はじめにモジュール化とはApplicationモジュールとLibraryモジュールに分けられる(他にもいくつかあるがここでは大きくこの2つとしている)ということと，それらの性質を示しています．その後に3つの観点から導入の利点を示しています． 特に3つ目の循環参照をコンパイル時に縛ることができるというのは，個人的に大きな利点だと考えています．明確なアーキテクチャの元呼び出しのルールを決めていればその必要はないかもしれません．しかしながら，機械的に縛ることができるのは，気が付かないうちに間違ったことをしてしまわないためにもその意義は大きいと思います．

第2章 (pp. 38 - 69)

第2章はこれまで:appのモジュールで記述されていた殆どの処理を:legacyへと移すことをはじめの一歩としようと提案している章です．なぜ:legacyとして切り出すのかを始めに示した後に，ApplicationモジュールとLibraryモジュールの相違から生じるコンパイルエラーについて話しています．ここでは個別の事例を2つ紹介していますが，後半の話が大きいです．ここで伝えたいことは言語やAndroidAPIの仕様・背景を知ることの重要性です．実際にこの処理を行ったときはもっと多くの問題点が出ましたが，そのいずれの問題点にも言えることです．

AndroidDevelopersには，apply plugin: 'com.android.library'とすればそれはLibraryモジュールとして扱うことができます✌のような記述しかありません．しかし，そこには初心者には大きな行間があることを意識してほしいというのがこの章を設定した狙いです(自戒)．スライド中では明記し損ねていますが，settings.gradleにモジュールを追加することなども忘れないようにしましょう．

第3章 (pp. 70 - 107)

第3章は，モジュールを追加するということを主体にbuild.gradle周辺で起きる問題について話している章です．複数のモジュールになることで起きる問題に着眼点を置いています．複数のモジュールで共通の値やリソース的なものを扱うにはどうしたらいいかという例としてBuildConfigを用いています．

また，モジュールをimplementationでつなぐか，apiでつなぐかと単一モジュールで扱っていると深く考えないものについても基礎的な範囲を網羅しています(compileOnly等他にもありますがそれはおいおい)．このimplementation or api問題はモジュール間の制約の強さに関わるものです．すべてをapiにしてしまっては制約を強くするというモジュール化の恩恵を大きく受けられない問題もあるのでここで触れました．

第4章 (pp. 108 - 141)

第4章は，モジュール化を行っていく上でリファクタリング的操作が必要なケースとその対処法について示している章です．この章は特に特定のアーキテクチャに則らずに開発が進められているケース等で大きく役に立つことが予想されます．ここではDIPを主眼に置いてその威力を示しています．ここではDIPを示しましたが，Strategy Pattern等でも同じような効果をもたらすことが可能です．また，ここでは深く書きませんでしたが，BaseActivityのようなものも障壁になるケースが多いため，そこに書かれている処理を適切な箇所に処理を移動させる必要があります．

実際に作業を進めるとこの章に該当することが作業の大多数を占めます．マルチモジュール化はリファクタリングとしての作業の色が強いと感じています．ここで示したようなDIPを駆使する，あるいは筋力💪で解決する等地道にやっていく必要があります．

第5章 (pp. 142 - 162)

第5章は，マルチモジュール化とJetPackとの組み合わせのうち，効用の高いものとしてNavigation Componentを紹介している章です．誤解をしてほしくないのは，例えばLiveDataやViewModel，Roomと言ったものがモジュール化と相性が悪いと言いたいわけではありません．むしろここで上げたようなものはマルチモジュール化する・しないに関わらず近代のAndroidアプリケーション開発では多くの場合強力な武器となります．この章で示したいのは，Navigatoin Componentの遷移の仕組みはモジュール化での遷移の仕組み上でも実践できますということです．

ここでは，詳細の実装に踏み入って話が脱線しそうだったので，Nested NavGraphという概念(NavGraphを複数のxmlに分け，適宜<include />できる仕組み)を示し，これを活用することで，各モジュール間での遷移もNavigation Componentを経由させる事ができることを示しています．具体的な遷移手法についてはスライドでは割愛しましたが，モジュール間をDeepLinkで遷移する方法等があります．

加えて，この方法を取ると部分的なモジュールにNavigationを導入するということも可能であるため，段階的に導入することができます．

第6章 (pp. 163 - 192)

第6章は，タイトルの回収です．継続的に機能開発を進めながらマルチモジュール化するにはどうしていくのがいいのか，私のなかでの方針を書いています．基本的には2から5章で示したテクニックやtipsを駆使しながら進めるといいという流れです．:legacyというモジュールに切り出す作業(第2章)さえ済んでいれば，急ぎの機能開発は:legacyにて行えばこれまでと全く同じ開発体験を提供できるというのがポイントです．

その上で，

  • 下のレイヤーからモジュール分割を行うこと
  • 新たなモジュールは:legacyへの依存を持たないようにすること

を意識することで，継続的に機能開発を進めながら，モジュール化を行うことができます．この手順の2つはチームでのコミュニケーションが大切です．しっかりとコミュニケーションをとりながらやっていくことが大切だと考えています．

感謝

@wakwak3125 さんには感謝しか無いです．こんな大きなことを任せてもらえてとっても勉強になりました．また，この作業の過程で多くのアドバイスをくださった @swiz_ard さん，@MalvinSutanto さん，インターンの機会をくれたCTOの @kawasy さんや人事の @amanda__mt さんにも感謝です．

雑記

DroidKaigiの存在を初めて知ったのはDroidKaigi2017のハッシュタグのついたtweet(確か@e10dokup)を見たことでした．こんな面白いイベント絶対に翌年は参加したいと思った記憶があります．

大きな期待を胸に参加したのはDroidKaigi2018でした．この年はアプリのコントリビュートも頑張りました．twitter上でしか見たことのないようなレジェンドな方々にPRをレビューされて震えていました．期待を大きく超えた胸の高鳴る多くのセッションを聞いてアプリ開発欲が爆発しました．また，こんなふうに登壇という形でDroidKaigiに関わることへの憧れも大きくなり，絶対に数年のうちに一度は登壇してやる！！と強い気持ちを持ったのを今でも覚えています．

DroidKaigi2019は卒研発表と日程が被って本気で卒業をとるかDroidKaigiを取るか悩みましたが泣きながら卒研発表を選びました．

そして，DroidKaigi2020では運良くスピーカーとして選ばれたのはすごく嬉しかったです．

こうやって振り返ってみると，DroidKaigiによって私のAndroid開発の知見やモチベーションはドライブされていたなと痛感します．そういうコミュニティを作ってくれる運営の方々への感謝を忘れずに，次のDroidKaigiでも何らかの形で関わりたいと思います！！！！