DroidKaigi 2019にてDaggerとModularizationの話をしました
DroidKaigi2019、スタッフの皆さんを始め、非常に有意義な時間を過ごさせて頂きまして、どうもありがとうございました。
僭越ながら 2/7(Thu) の 16:30 からのセッションにて "From Monolithic to Modularized codebase with Dagger" というタイトルで発表させていただきました。初日の最後の時間帯でしかも50分枠ということで、参加頂いた皆さんはなかなか大変だったかと思いますが (疲労感的に) 、内容以上にその辺のこと (早く飲みたい、疲れた...etc) をすごく気にしながら喋らせて頂いたつもりです (何
何についてのお話だったのか
Dagger2を使って依存管理しているアプリにおいて、app モジュールに全てのコードが入った状態 (monolithic) から1つのfeatureをsub moduleに切り出していく過程を紹介する、というプレゼンでした。
伝えたい考え方そのものは結構汎用的な話だったと思うのですが、どう考えても泥臭い話になることが見えていたので、具体例 (どんなアプリを題材にするのか) の紹介であったり、自分がどういう意図でDagger2を使っているのか、そもそもmodularizationって何が嬉しいのか、といったbackgroundの説明を大事にしたつもりです。
結果、backgroundの説明に約30分、modularizationの過程の紹介 (本題) に15分、dynamic feature moduleを試してみた話 (せっかく来てもらっているので新しい話もしたかった) に5分、といった内容になりました。50分という長丁場でしたが、「メモを一生懸命取らなくても分かってもらえる話を目指した」と前置きした通りの50分になっていたら嬉しいなぁ…と思ってるのですがいかがでしたでしょうか。。。
Daggerとワタシとmodularization
Dagger2そのものは、2016年に仕事のprojectに導入された事をきっかけに勉強し始めました。ですがDI (Dependency Injection) に関してはもうずっと前から興味を持って取り組んでいて、仕事のAndroidアプリ開発の中でもちょいちょい意識してました。意識していた、というのは、満足行くように出来てなくてモヤモヤしてたんですね。Dagger2のような高尚かつ魔法のような道具（←第一印象）を使えば、そのモヤモヤも解決できるだろうし、個人的に凄く拘りのあるActivity lifecycleに起因するデータ管理の解決にもなるんじゃない？なんて、高い期待を持って取り組んでいたものです。
ということで、Dagger2の正体を (自分の狙いに関するベクトルで) 理解していく日々を過ごしてました。このQiitaの記事なんかはまさにその気持ちが高まっている時に調べたものですな。
そして、そこから半年くらい色々見ていく中で「あれ、 @Module と @Component の関係って、"部品とその組み立て" みたいで面白くない？」ってことに気づきまして。 @Module が とある機能領域のロジックやUIパーツを提供する "部品" と捉えて全体を開発していく、ってキレイなのでは？なんて思ったんですねー。
だけど、実際のお仕事でそこまでやろうとするにはタイミングが悪かった (出来上がったものを、そのような状態に持っていくのはコストが高すぎる) こともあり、しかも自分は US プロジェクトをたった一人でリモートから参加していた、という背景もあって、話半分で終わりました。
しかしそこはハイ意識なワタクシ、「やっぱりやってみたいなぁ。。。」とずっと思ってて、結局プライベートで出しているアプリを全部壊してイチから書き直すことで、チャレンジすることにしました (←ここが2017年秋) 。
時間はかかってしまったものの (仕事の状況だけでなく、人間のモチベーションは常に高いわけでは無い) 徐々に形が見えてきて、しかも会社でやっているようなアプローチを丸々コピーしつつもそこにAndroid Architecture Componentを導入する余地を研究しながら進めたりしていて、楽しみながらいい感じに育っていきました (2018年の夏くらいにアプリ再リリース & Instant app対応もした) 。
DroidKaigiに向けて
そんな最中DroidKaigi2019のCFP募集が始まりまして。
昨年のDroidKaigiのCFPに落選した時、同僚の @mhidaka さんに「ねーねー、なんで毎年毎年CFP通らないの？」と相談したところ「CFPちゃんと書いてないでしょ？」と、サンダーバキュームボールばりの直球を受けたことを思い出し、今年はちゃんと書くことにしました (4回目のCFP挑戦にしてついに)。
今年に入って、弊社には一段と著名な方が続々と入ってらっしゃいまして、そんな状況に相乗りするかのごとし何人かの方にreviewをしていただき (うふふ) 、おかげさまで提出した3つのうち1つが通過しました。ニッチ路線も出すことでよりcoverageを上げよう！と書いた PreferenceFragmentCompatを使って超簡単に設定画面を作ろう というセッションが通過しなくて本当に良かったです。
modularizationのお話なので、せっかくなら！と思って、11月はdynamic feature moduleに挑戦しました。ところがmodule化の延長でサクッと対応できるシロモノではない事が分かった上に、当日デモをするにも、後ほどyoutubeで動画が公開されることを考えると著作権的に色々マズそうな画面が多く (汗)、頑張った割には地味なoutputになりました (一応手元にはいつでも公開できる状態にはなってる) 。
12月に入ってからgoogle docsにagendaを書き始め、年末年始はプレゼンの作成、、、と進めていたところ、まさかの1月、3週間のUS出張が決まりまして、google本社のお膝元のMountainViewにてプレゼンの練習およびスライドの手直しをしていくことになりました。形から入ることが大好きなワタクシには、ある意味、最高の展開です。
一生懸命そのスペシャル感を醸し出そうとしたのですが、、、
1月は雨季ですし、日の長さも日本と変わりませんし、日本よりは暖かいとはいえ寒い時間帯も多いですし、何より仕事が忙しかった、ってことで、スペシャル感どころかただのピンチに陥っただけでした orz
当日
開始3分前くらいまで広めの会場に20人くらいしかいらっしゃらなく、「全員前に来てください！ぜひぜひ！」なんて言っちゃおうかな！なんて考え始めましたが、続々と来て頂き、本当に嬉しかったです(泣)。
途中スライドが映らなくなったり、カメラが定点だったことをまったく気にせずスライドの前をうろちょろしたり、色々アレだったところもありますが、なんとか終わってよかったです。発表中、何度も皆さんに「ですよね！？」なんて投げかけさせてもらいましたが、その度に頷いて目を合わせてくださった何人かの皆様、特にありがとうございました (泣)。
疑問、質問、ご相談、対応しかねることもあるかと思いますが、お気軽に @tsuyogoro までいただければと思います。
なお、来年またプレゼンに挑戦するかどうか、今は全く考えられません (疲)。何よりネタ切れです（ピンチ）。
Android アプリ設計パターン入門 を執筆いたしました
・2年前、電機メーカからWeb業界へ転職した際に「Web業界で働くからには、ブログを書くぞ！」と気合いを入れて作ったものの、一度も書いておりませんでした。そういえばあの頃「Web業界ならアニメもある程度知らないと！」と思い、シュタインズゲートをゲオで借りてきたものの全く興味が沸かず、結局何も学ばずに今に至ります。みなさまこんばんわ、ご機嫌いかがでしょうか。
さて、この度「Android アプリ設計パターン入門」という本に執筆に関わらせていただきました。
著名な方々の頭の中が覗ける素晴らしい本が出来上がったのではと思いますし、読者はこの本を通じて更に仲間を作るきっかけにもなりそうで非常にワクワクする一冊ですね。クラウドファウンディングに協力頂いた皆さま、かなりお待たせしてしまったようで、大変申し訳ありませんでした。
去年の夏くらいに同僚の @mhidaka さんにお誘い頂いたのがきっかけでして、自分は4章の「差分開発にみる設計アプローチ」を担当させていただきました。物議を醸す4章になってしまったのではないかとビクビクしているのですが、この場を借りて、この執筆の背景や自分の思うことなどを語らせて頂ければと思います。
まず始めに、自分はあまりこういう技術書を書くタイプだと思っていないんですね。技術書はブログよりも遥かに信頼できるリファレンスであるべき、というイメージがあり、「あくまでプロダクトを作るために技術を習得する」が色濃くて「目的が満たされれば必要以上に深掘りしない」というスタンス (正直これが良いのかどうか日々葛藤) の自分は、そんなリファレンスが作れるとは思えませんでした。
という話を @mhidaka さんに一番始めにしたのですが「生きた設計、現場感、を書籍に残すのは大いに意義があると思うので、そういうスタンスの人が書く記事というのは読者にはかなり嬉しいはずです」というまさかの答えが返ってきました。まぁ実際、自分が他の会社に所属してて「うーん、上手く行かないなぁ」と燻っているのだとしたら、今を時めくメルカリがどのような状況で開発を行っているのかという情報が書籍に書いてあれば飛び付くなぁと(笑)。そんなこともあり、良くも悪くも現場で起こっていることを詰め込んで書くことにしました。
ただ、取り上げる題材が(1年前にスクラッチから書き直したUSのプロダクトではなく) 創業期から積み上げてきたレガシーなプロダクトの方であったため、油断したらネガティブな内容が増えてしまう事が予想されました。ですので、なるべく「この失敗からこういうことを学んだ」「この失敗は、このように改善した」と、ポジティブな方向へ話が流れることを意識して書いていったつもりです。
特に推しポイントとしては「大きな改善に挑戦したターニングポイント」のお話です。「レガシーなコードが全員の方向性をバラバラにしてしまっていた状態」が「チーム全員が一定の納得感を持って進める事ができる状態」に改善された、割とレアな話だったのではなかろうかと思っています。
とはいえ、もちろん (?) スマートな話では無い訳です。技術的負債を返したい vs そんなことどーでもいいから機能を出す、の戦いは起こりましたし、自分はまさにその真ん中で機能開発をしてたため、本当に思い出したくないくらい辛かったですし(笑)。でもなんていうか、その時きちんと真ん中から逃げなかったからこそ、今、素晴らしいチームの状態を実現できているんだろうなと噛みしめる日々である訳です。よって、負債を返したいけど…と燻ってる方に、このリアルなストーリーが "勘所的なものの気付き" になれば良いのかなぁと思いながら書きました。「何をしたのか」「何が起きたのか」が書いてあります (期待感を煽りすぎないように書いておきますが、内容は割と当たり前のことですw) 。「あのメルカリさんがこうやって改善したらしいですよ！うちにもやらせてください！」みたいなネタに使ってください (笑)。
全体的に「チームとしてどうなのか」という所に頭が向いた内容かなと思いますが、去年のMercari Tech Conferenceでの自分の話もチームワークに頭が向いてますし、今の仕事の役割もそういう所まで担ってます。なので、"100%技術" みたいな内容にはどうしても成り得ない人が書いた記事だと思って読んでもらえればと。逆に、そういう人が書いた話がどのように受け止められるんだろうという所に (マサカリを恐れる気持ちと並行して) 興味を持ちつつあります。
ということで「Android アプリ設計パターン入門 」、どうぞよろしくお願いいたします。
(裏話)
「リアルさをもっと伝えたい」と思い、当時開発中に殴り書きした設計図を引っ張り出してきて初稿に貼り付けて提出しました。これが @7gano さんにウケまして、まさかまさかの、そのまま本に載ることに(笑)。今見返すと「き、き、きたない…」という感じなのですが、「設計をきちんとする人は、きちんとした設計図を書くに違いない」と考えていた時期が自分にもありましたので、昔の自分に見せてやるという意味でもこのまま送り出すことにしました。みなさん、暖かく受け入れてあげてください(笑)。
