2020-03-04

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

はじめに

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

さて，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でも何らかの形で関わりたいと思います！！！！

2019-05-13

CyberAgentのインターンシップに参加した話

みなさんごきげんよう．chigichan24です．

今日はCyberAgentでの就業形インターンシップに参加したことを書こうと思います．

受けるまで

実は遠い昔，一度インターンシップの選考を受けたときお祈り🙏🙏🙏🙏を頂きました．それもあって風土と自分の思考・思想が異なるんじゃないかとそこそこ渋りましたが，やっぱり気になっていたので受けてみました．

実際に選考に通るまでの流れは以下の感じです．コーディングテストとかはなかったんですが，私のGitHubにpublicで上げてるコードは見られてたっぽい(ぽい)．

書類審査📝

書類を書きました．
まじで記憶にありませんが，開発経験とかインターンの経験を書いた気もします．書けそうなネタが人より少ないタイプの人間(コンテスト入賞とかがない)でしたが，それとなく書きました．
GitHubアイコンはもちろんあれで出しました．

github.com

一次面接🤓

人事の方とお話しました．The 面接みたいな堅い感じではなかったです．
設計(アーキテクチャ)とかを意識したサムシングを勉強したいです．と言いました．
「どういうものを作りたいのかの具体性がないのでどの部署を勧めていいかわからない」とクリティカルにありがたい指摘を頂いたので，まあ落ちたのだろうと思いました．
技術面談かと思ってたので，これは見当違いなことを口走ったなと思いました．

二次面接🧐

ありがたいことにある部署を勧めてもらいました．完全に落ちたと思ったのでビッくらポンでした．
ここでは楽しく会話をした記憶しかないです．現役エンジニアと話すのは面接とはいえめちゃくちゃ楽しいものです．
Kotlin coroutinesとReactive Xのpros and consについて話したり，DroidKaigi2019のFluxアーキテクチャの話やAndroid設計本のことを話したりしました．
面接ではなく完全に雑談の会でした．
雑談中に，来てほしい的な発言があって，行くことが確定しました(?)

働いてみた

AbemaTVのAndroidエンジニアとしてのインターンを受け入れてもらえました🎉🎉🎉 SNSやブログ上で知っている人が存在していて，おもろかったです(何様)

実はインターンの期間はもともと一ヶ月の予定でしたが，楽しかったしリリースまでいたいという思いが高まったので二ヶ月お世話になりました．

やったこと

走っていた新機能開発のプロジェクトにぽんと突っ込まれました．ここにタスクがまとまっているから自分をassignしてPR出してみたいな感じで雑にタスクが降ってきました．そこそこ不安がっていましたが，実際にはPR上で丁寧にレビューをしていただき私の理解度に合わせて適切な粒度で方針を示してもらいめちゃくちゃ良かったです．takahiromさんは神．

基本的にはコードを書いてPRを出すという感じのスタイルだったのですが，不明瞭な点について，別のチームの人やデザイナーさん等と話すということをしたり，チームの人が出したPRに対してレビューをしたりと社員さんとほとんど対等みたいな感じで働かせていただけたのは非常にやりやすかったです．

書いたコードのジャンル(?)も多種多様で，

ロジックっぽい部分．
UIに近い部分．
Kotlin化
バグ修正

等，AbemaTV-Androidのいろんなところに手を出させていただきました．

最終日に何気なくみてみたら，合計で30個くらいのPRを出していました．当然各PRの重さはバラバラなので単純に個数で計測することに意味はないんですが，「おおーっ」となりました．

そのほか

CA.apkというイベントや，社内で行われていたLT会での発表の機会をいただきました．タイミング的に，両者ともたまたまという感じだったんですが，機会提供をしてもらえて嬉しかったです．

cyberagent.connpass.com

AbemaTVの番組を実際に作っているスタジオの見学に行きました．コンテンツを提供する側での現場を見れて面白かったです．

引っ越しを経験しました．会社の引っ越しの経験なんてそうそうすることないので，良かったです．てっきり自分の荷物は自分で運べみたいな感じかと思っていましたが，そんなことはなくて，普通に業者さんが運んでくれました(それはそう)

www.cyberagent.co.jp

感じた

いくつかの企業でこれまでもインターンシップをした事があったのですが，そのどこにもなかった(いい意味での)異質さがCyberAgentにはありました．

それは速度感と規模感を両立しているところでした．ものすごいスピードで開発を進めつつ，その市場の規模をどんどん拡大していく姿は2ヶ月しかいなかったインターン生でもものすごく感じました．

また，いろんなチームがこだわりとチーム観を持って仕事をしているなとも思いました．デザインではこのように表現したいけど，クライアントにとってそれを実現するのはものすごく工数がかかる問題をどうしようというケースがあります．そのときに「ここは妥協したくない」というデザイナーさんの意見と，「ここはこういうふうに実装したい」というクライアントチームの声が毎度いい改善案(解決策)を生み出していて，すごいと思いました(小並感) ．