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

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ヶ月しかいなかったインターン生でもものすごく感じました.


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

反省点

私の考えていることが基本的に浅はかで,それちゃんと考えてるの?というPRを出してしまったことがいくつかありました.

  • 動くは動くけど,それでいいのか?という部分をもっと深く追う必要があり,なにがどのように動くのかをもっと意識する必要があるなあと改めて感じました.
  • 例えば,AOSPでのコードをちゃんと参照して問題ないということを示されたりしたので,Androidそのものがどのようなコードで書かれているかを深めたいです.


コードを書く速度が社員さんと比べて遅い.

  • ドメイン知識がないだけだとはじめは思っていましたが,明らかに遅い.
  • ある機能を追加したいときに何をどこに,どう書くかを高速にイメージする訓練をしたいです.そのためにはもっともっと引き出しを増やす必要があると深く痛感しました.

おわりに

インターンに参加したときに裏テーマとして,「人日計算の頭数に入れられるくらい一人前のエンジニアとして力になりたい」というのがありました.これを最終日に打ち明けたら,それは初日から達成していたよ(?)と言われたときはめちゃくちゃ嬉しかったです.

すごくいい環境で働かせてもらえて,CyberAgent(というかAbemaTV)の雰囲気を感じ取ることができ,また自分の技術力の向上も得られたので本当に良かったです.もっと精進します.

どうでもいいこと

渋谷のランチ事情に詳しくなった.

2018年を振り返る

chigichan24です.研究のプログラムの出力待ちにちょこちょこ記事を書いています論文を書け. 一年早いですね.今年もいろいろ成長した気がするので,成長記録として見てください.

昨年に比べoutputや評価される機会は減っているが,純度が上がっていると信じてる.

今年の大きな開発

所感

  • ネイティブアプリのエンジニアとして極めたいという思いが詰まった一年.
  • それでもって,インフラのお仕事やバックエンドを書く機会もしっかり持てている.
  • Kotlin,awsに関する知見が増えた.

発表したLT等

  • kosen12s LT #1
  • kosen12s LT #2
  • yakiniku-LT(?) #2
  • KosenLT会
  • 第17回 学生LT
  • shibuya.apk #30

所感

  • kosen界隈に関わり過ぎでは...
  • 目標にしていたshibuya.apkで話せてよかった

出場したコンテスト

  • ACM-ICPC国内予選
  • ISUCON 8
  • MashupAward IoT部門,学生部門
  • GUGEN2018

所感

  • 予選落ちが多かったので精進.

読んだ本(よかったやつ)

peaks.cc

techbooster.booth.pm

techbooster.booth.pm

peaks.cc

Kotlinイン・アクション

Kotlinイン・アクション

Androidアプリ開発のためのKotlin実践プログラミング

Androidアプリ開発のためのKotlin実践プログラミング

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャ

所感

研究関連

  • Mendeleyによると65本論文を読んだらしい.まとめる以前や打ち込んでない論文を入れると多分100行かないくらい読み込んだっぽい.
  • きれいなC++17書けてない.頑張ろう...

ブログ

テクノロジーな記事を何本か書けた.二番煎じにならないことを目標にしていたが....

chigichan24.hatenablog.com

chigichan24.hatenablog.com

qiita.com

qiita.com

qiita.com

その他

  • いろんなカンファレンスや勉強会に行って知見を広めた.
  • 設計論について色んな人と議論できた.
  • kosen12s LTはadminとして頑張った.
  • 何本かギークな記事を書いた.
  • OSSに貢献できた.
  • キャッシュレスが加速した.

来年に向けて

  • Androidを始めとするネイティブアプリのエンジニアとしての尖りを強くする.
  • Androidしかできないと思われない用に他の技術の知識量をもっと増やす.
  • 研究を綺麗にまとめる.
  • input / output を止めない.