Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
運用3年のタップル誕生でJavaからKotlin移行した話
Search
mukky620
October 03, 2017
Programming
0
1.1k
運用3年のタップル誕生でJavaからKotlin移行した話
2017/10/02 CA.apk #4 資料
mukky620
October 03, 2017
Tweet
Share
More Decks by mukky620
See All by mukky620
Firebase A/B TestingとRemote Config を最大限に活用する方法
mukky620
1
1.4k
Firebase A/B Testing Targeting Tips
mukky620
0
2k
Kotlin導入してみたかったけど結局間に合わなかった…
mukky620
0
3.7k
Other Decks in Programming
See All in Programming
ピラミッド、アイスクリームコーン、SMURF: 自動テストの最適バランスを求めて / Pyramid Ice-Cream-Cone and SMURF
twada
PRO
10
1.1k
カラム追加で増えるActiveRecordのメモリサイズ イメージできますか?
asayamakk
4
1.9k
OpenTelemetryでRailsのパフォーマンス分析を始めてみよう(KoR2024)
ymtdzzz
5
1.9k
cXML という電子商取引の トランザクションを支える プロトコルと向きあっている話
phigasui
3
2.3k
PHP でアセンブリ言語のように書く技術
memory1994
PRO
1
160
ヤプリ新卒SREの オンボーディング
masaki12
0
100
Tuning GraphQL on Rails
pyama86
2
1.2k
タクシーアプリ『GO』のリアルタイムデータ分析基盤における機械学習サービスの活用
mot_techtalk
4
140
CPython 인터프리터 구조 파헤치기 - PyCon Korea 24
kennethanceyer
0
250
WebフロントエンドにおけるGraphQL(あるいはバックエンドのAPI)との向き合い方 / #241106_plk_frontend
izumin5210
4
1.2k
Modern Angular: Renovation for Your Applications
manfredsteyer
PRO
0
240
LLM生成文章の精度評価自動化とプロンプトチューニングの効率化について
layerx
PRO
2
160
Featured
See All Featured
What's in a price? How to price your products and services
michaelherold
243
12k
Designing Experiences People Love
moore
138
23k
Scaling GitHub
holman
458
140k
Automating Front-end Workflow
addyosmani
1366
200k
Code Review Best Practice
trishagee
64
17k
Facilitating Awesome Meetings
lara
49
6.1k
The Language of Interfaces
destraynor
154
24k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
Designing for humans not robots
tammielis
249
25k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
32
1.8k
Unsuck your backbone
ammeep
668
57k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
329
21k
Transcript
運用3年のタップル誕生でJava からKotlin移行した話 2017/10/02 CA.apk #4 1 向中野 亘 mukky620
• 向中野 亘 (むっきー) • ServerSide Engineer ↓ Android Engineer
2 自己紹介
1. JavaからKotlinへの移行理由 2. 移行の前にチーム内で行なった事 3. 移行で悩み・苦労した点 4. まとめ 3 Agenda
なぜJavaからKotlinに移行?? 4
1. Android開発言語としての正式言語サポート 2. モダンな言語仕様 3. Javaとの互換性・相互運用性 4. 社内のプロダクトでの開発事例・移行の兆し 5. アーキテクチャ改善と合わせて
6. Javaエンジニアなら習得コスト軽 5 移行理由
Kotlinが書きたいという モチベーション! 6
まず、移行始める前に行なった事 7
• 内容 ◦ Kotlin Koans(全42問)を4週くらいに分けて各自解いてくる。 (https://try.kotlinlang.org) ◦ 当日答え合わせして経験者からの補足と別解、プロダクト での実践的な事例等々の解説をもらう。 8
週1でのKotlin勉強会の開催
9
10 勉強会の良かった点 • 自習でつまづいたところを直接聞く事で体系的に学べるので 理解が早い。 ◦ プロダクト内での事例を交えたりするのが良い。 • ただ話を聞くより自分なりに考えて問題を解いてくるという事が 身になる。
11 勉強会の悪かった点 • 問題文が全て英語なので読み取りづらい部分があった。 ◦ 完全に自分の英語力の問題…
12 その他 • Kotlin入門までの助走読本 (https://drive.google.com/file/d/0Bylpznm149-gTGRjOFRkW m9PODg/view) • Kotlin Blog(https://blog.jetbrains.com/kotlin/) •
Kotlinアドベントカレンダー • FRESH!のソースを参考に。
あとはもう書いて覚えようという感じで Kotlin移行始めました! 13
• チームメンバー4人(経験者1人、未経験3人) ◦ 経験者はチームに1人は必要だと思う • 施策開発は止められないのでKotlin移行は平行で行う • プロダクトへすぐ導入 ◦ ユーザー影響少なそうな画面(Activity/Fragment)から移行
14 タップルでのKotlin移行の進め方
• レビュアーアサインについては経験者1人は必須で3人で見 る。 ◦ 経験者は基本的にKotlinらしい書き方という面に特化して レビューしてもらう。 ◦ 仕様面のレビューに関しては経験者以外の他のメンバー で見る。 15
タップルでのKotlin移行の進め方
この体制で最初のうちは ガンガン進めていたのですが… 16
進めてるうちに 悩んだり・苦労した事がちらほら… 17
なので今回はそのあたりを 抜粋して紹介したいと思います 18
悩み・苦労した点 19
施策開発と平行で進めるの辛い…
• 施策開発優先なのでKotlin移行だけの専任ラインは作れず、 途中から思うように進捗が芳しくない感じに… • Kotlin化のプルリクをmasterマージしたけど、施策開発のみリ リースしたいためrevertやタグ切り戻し発生… • 施策開発のプルリク優先しているため、Kotlin化のプルリクが 溜まり始める… 21
施策開発と平行で進める
NonNullかNullableか 分からなくて辛い…
• 昔のJavaソースに特に多いがNonNull、Nullableアノテーション ついてない… • 正しいAPI仕様書がなく、APIのレスポンスパラメータが必ず 入ってくるものなのかどうかが分からなくて辛い… ◦ ちなみにparserはGson使っている 23 NonNullかNullableかが分からない
タップルの仕組み 24 APIレスポンス周りなぜ辛いのか? Entity (レスポンスを格納す るObject) Dto (表示等で使いやす いようにEntityを ConvertしたObject)
Server API通信 Converter (Dtoへの変換処 理)
タップルの仕組み 25 APIレスポンス周りなぜ辛いのか? Entity (レスポンスを格納す るObject) Dto (表示等で使いやす いようにEntityを ConvertしたObject)
Server API通信 Converter (Dtoへの変換処 理) Gsonでparse
26 Entity(Javaソース) 例えばアイテムによって はcaptionが返却されない とすると。 caption以外→NonNull caption → Nullable
タップルの仕組み 27 APIレスポンス周りなぜ辛いのか? Entity (レスポンスを格納す るObject) Dto (表示等で使いやす いようにEntityを ConvertしたObject)
Server API通信 Converter (Dtoへの変換処 理) EntityをDtoに変換する処理
28 Converter shopItemResponseはJavaソースの呼び出しなのでプラットフォーム型になる が、caption以外はAPIの仕様上NonNullが保証されているとする。
29 Dto この場合、Dto側は全てNonNull で定義してしまっているので、 例えばcaptionが返却されな かった場合にNonNull定義の captionにnullが代入出来てしま い、 Null安全ではなくなる
タップルの仕組み 30 APIレスポンス周りなぜ辛いのか? Entity (レスポンスを格納す るObject) Dto (表示等で使いやす いようにEntityを ConvertしたObject)
Server API通信 Converter (Dtoへの変換処 理) 変換後のDtoのフィールドをNonNull定義にすべ きかNullable定義にすべきか分からない
そんなのサーバーの人に確認し てもらえば良いんでない?? 31
• Kotlin化のためにサーバーの人にAPI毎のレスポンスの確認 取ってもらうの結構コスト… ◦ サーバーはNode.jsでレスポンスはjson • API数はAndroidで使ってるだけでも約130〜140くらいある …ヒィ。。 → 絶賛サーバ側でAPI仕様書作るためのツール開発中!
32 コストが…
書き方の自由度が高過ぎて悩む… (ときがある)
• この時はこの書き方がベストだという事がないため慣れないう ちは迷う事が多々ある… ◦ 特にJava移行組は余計に迷う ◦ もっと良い書き方があるんじゃないかと迷いだして時間が 経つ… ◦ スコープ関数の使い分けとか自分的に特に迷う…
34 書き方の自由度が高い
35 スコープ関数
36 スコープ関数 apply, run, let, also, with
ちなみに皆さんちゃんと 使い分けられてますか?? 37
自分はスコープ関数の使い分けが中々理解できず、 経験者の方から説明していただいた使い分けイメージを パクって参考にして使い分けています。 ※あくまでもイメージなので全て当てはまるわけではないと思いま す! 38 スコープ関数の使い分け
• 意味合い的に適用する場合に使用 • よくcreateInstanceとかで使用するイメージ • 基本的に(自身)戻り値を使用する • インスタンスのプロパティが変化する時とかに使 用 39
apply
• 同じ戻り値である必要がないまたは同じ戻り値を 変えたい時に使用 • this.func() ◦ • func(this) X 的なイメージで使用している。
40 run
• 同じ戻り値である必要がないまたは同じ戻り値を 変えたい時に使用 • Nullableに対してよく使用 • func(it) ◦ • it.func()
X 的なイメージで使用している。 41 let
• 自身を返却する • itを使うけどitには変化を与えない • 基本的に戻り値を使用 ※正直まだ1度も使えてない… 42 also
最終的にはたろーさんの下記サイト見てます。 https://qiita.com/ngsw_taro/items/d29e3080d9fc8a38691e 43 スコープ関数の使い分け
うーん…使いこなしたい。。 44
45 まとめ
• JavaからKotlin移行は当初思っていたより大変だった。 → 特に運用年数長いほど負債が多いからより大変。 • 施策開発と平行で進めるのは難しい。 → 施策と施策の谷間で地道にコツコツやるか、もしくは出来る のであれば施策開発止めて集中コミットするのが良いのかも しれない。
46 まとめ
• NonNull、Nullableアノテーション大事! → convert前に明示的にしっかりつけるべき。 • 書き方の自由度が高いので慣れないうちは迷いがち。 → 都度相談・議論しながらチーム内で共通認識を持つ事が大 事。コード規約をしっかり定めるのが良い。 (スコープ関数も使いこなしたいですね)
47 まとめ
この経験を活かして より良いKotlin移行を模索しながら 引き続き進めていきます! 48
ご静聴ありがとうございました! 49