運用３年のタップル誕生でJavaからKotlin移行した話

2017/10/02 CA.apk #4 資料

Transcript

1. 運用３年のタップル誕生でJava からKotlin移行した話 2017/10/02 CA.apk #4 1 向中野 亘 mukky620
2. • 向中野 亘 (むっきー) • ServerSide Engineer ↓ Android Engineer 2 自己紹介
3. 1. JavaからKotlinへの移行理由 2. 移行の前にチーム内で行なった事 3. 移行で悩み・苦労した点 4. まとめ 3 Agenda
4. なぜJavaからKotlinに移行？？ 4
5. 1. Android開発言語としての正式言語サポート 2. モダンな言語仕様 3. Javaとの互換性・相互運用性 4. 社内のプロダクトでの開発事例・移行の兆し 5. アーキテクチャ改善と合わせて 6. Javaエンジニアなら習得コスト軽 5 移行理由
6. Kotlinが書きたいという モチベーション！ 6
7. まず、移行始める前に行なった事 7
8. • 内容 ◦ Kotlin Koans(全42問)を4週くらいに分けて各自解いてくる。 (https://try.kotlinlang.org) ◦ 当日答え合わせして経験者からの補足と別解、プロダクト での実践的な事例等々の解説をもらう。 8 週１でのKotlin勉強会の開催
10. 10 勉強会の良かった点 • 自習でつまづいたところを直接聞く事で体系的に学べるので 理解が早い。 ◦ プロダクト内での事例を交えたりするのが良い。 • ただ話を聞くより自分なりに考えて問題を解いてくるという事が 身になる。
11. 11 勉強会の悪かった点 • 問題文が全て英語なので読み取りづらい部分があった。 ◦ 完全に自分の英語力の問題…
12. 12 その他 • Kotlin入門までの助走読本 (https://drive.google.com/file/d/0Bylpznm149-gTGRjOFRkW m9PODg/view) • Kotlin Blog(https://blog.jetbrains.com/kotlin/) • Kotlinアドベントカレンダー • FRESH!のソースを参考に。
13. あとはもう書いて覚えようという感じで Kotlin移行始めました！ 13
14. • チームメンバー4人(経験者1人、未経験3人) ◦ 経験者はチームに1人は必要だと思う • 施策開発は止められないのでKotlin移行は平行で行う • プロダクトへすぐ導入 ◦ ユーザー影響少なそうな画面(Activity/Fragment)から移行 14 タップルでのKotlin移行の進め方
15. • レビュアーアサインについては経験者１人は必須で3人で見 る。 ◦ 経験者は基本的にKotlinらしい書き方という面に特化して レビューしてもらう。 ◦ 仕様面のレビューに関しては経験者以外の他のメンバー で見る。 15 タップルでのKotlin移行の進め方
16. この体制で最初のうちは ガンガン進めていたのですが… 16
17. 進めてるうちに 悩んだり・苦労した事がちらほら… 17
18. なので今回はそのあたりを 抜粋して紹介したいと思います 18
19. 悩み・苦労した点 19
20. 施策開発と平行で進めるの辛い…
21. • 施策開発優先なのでKotlin移行だけの専任ラインは作れず、 途中から思うように進捗が芳しくない感じに… • Kotlin化のプルリクをmasterマージしたけど、施策開発のみリ リースしたいためrevertやタグ切り戻し発生… • 施策開発のプルリク優先しているため、Kotlin化のプルリクが 溜まり始める… 21 施策開発と平行で進める
22. NonNullかNullableか 分からなくて辛い…
23. • 昔のJavaソースに特に多いがNonNull、Nullableアノテーション ついてない… • 正しいAPI仕様書がなく、APIのレスポンスパラメータが必ず 入ってくるものなのかどうかが分からなくて辛い… ◦ ちなみにparserはGson使っている 23 NonNullかNullableかが分からない
24. タップルの仕組み 24 APIレスポンス周りなぜ辛いのか？ Entity (レスポンスを格納す るObject) Dto (表示等で使いやす いようにEntityを ConvertしたObject) Server API通信 Converter (Dtoへの変換処 理)
25. タップルの仕組み 25 APIレスポンス周りなぜ辛いのか？ Entity (レスポンスを格納す るObject) Dto (表示等で使いやす いようにEntityを ConvertしたObject) Server API通信 Converter (Dtoへの変換処 理) Gsonでparse
26. 26 Entity(Javaソース) 例えばアイテムによって はcaptionが返却されない とすると。 caption以外→NonNull caption → Nullable
27. タップルの仕組み 27 APIレスポンス周りなぜ辛いのか？ Entity (レスポンスを格納す るObject) Dto (表示等で使いやす いようにEntityを ConvertしたObject) Server API通信 Converter (Dtoへの変換処 理) EntityをDtoに変換する処理
28. 28 Converter shopItemResponseはJavaソースの呼び出しなのでプラットフォーム型になる が、caption以外はAPIの仕様上NonNullが保証されているとする。
29. 29 Dto この場合、Dto側は全てNonNull で定義してしまっているので、 例えばcaptionが返却されな かった場合にNonNull定義の captionにnullが代入出来てしま い、 Null安全ではなくなる
30. タップルの仕組み 30 APIレスポンス周りなぜ辛いのか？ Entity (レスポンスを格納す るObject) Dto (表示等で使いやす いようにEntityを ConvertしたObject) Server API通信 Converter (Dtoへの変換処 理) 変換後のDtoのフィールドをNonNull定義にすべ きかNullable定義にすべきか分からない
31. そんなのサーバーの人に確認し てもらえば良いんでない？？ 31
32. • Kotlin化のためにサーバーの人にAPI毎のレスポンスの確認 取ってもらうの結構コスト… ◦ サーバーはNode.jsでレスポンスはjson • API数はAndroidで使ってるだけでも約130〜140くらいある …ﾋｨ。。 → 絶賛サーバ側でAPI仕様書作るためのツール開発中！ 32 コストが…
33. 書き方の自由度が高過ぎて悩む… (ときがある)
34. • この時はこの書き方がベストだという事がないため慣れないう ちは迷う事が多々ある… ◦ 特にJava移行組は余計に迷う ◦ もっと良い書き方があるんじゃないかと迷いだして時間が 経つ… ◦ スコープ関数の使い分けとか自分的に特に迷う… 34 書き方の自由度が高い
35. 35 スコープ関数
36. 36 スコープ関数 apply, run, let, also, with
37. ちなみに皆さんちゃんと 使い分けられてますか？？ 37
38. 自分はスコープ関数の使い分けが中々理解できず、 経験者の方から説明していただいた使い分けイメージを パクって参考にして使い分けています。 ※あくまでもイメージなので全て当てはまるわけではないと思いま す！ 38 スコープ関数の使い分け
39. • 意味合い的に適用する場合に使用 • よくcreateInstanceとかで使用するイメージ • 基本的に(自身)戻り値を使用する • インスタンスのプロパティが変化する時とかに使 用 39 apply
40. • 同じ戻り値である必要がないまたは同じ戻り値を 変えたい時に使用 • this.func() ◦ • func(this) X 的なイメージで使用している。 40 run
41. • 同じ戻り値である必要がないまたは同じ戻り値を 変えたい時に使用 • Nullableに対してよく使用 • func(it) ◦ • it.func() X 的なイメージで使用している。 41 let
42. • 自身を返却する • itを使うけどitには変化を与えない • 基本的に戻り値を使用 ※正直まだ１度も使えてない… 42 also
43. 最終的にはたろーさんの下記サイト見てます。 https://qiita.com/ngsw_taro/items/d29e3080d9fc8a38691e 43 スコープ関数の使い分け
44. うーん…使いこなしたい。。 44
45. 45 まとめ
46. • JavaからKotlin移行は当初思っていたより大変だった。 → 特に運用年数長いほど負債が多いからより大変。 • 施策開発と平行で進めるのは難しい。 → 施策と施策の谷間で地道にコツコツやるか、もしくは出来る のであれば施策開発止めて集中コミットするのが良いのかも しれない。 46 まとめ
47. • NonNull、Nullableアノテーション大事！ → convert前に明示的にしっかりつけるべき。 • 書き方の自由度が高いので慣れないうちは迷いがち。 → 都度相談・議論しながらチーム内で共通認識を持つ事が大 事。コード規約をしっかり定めるのが良い。 (スコープ関数も使いこなしたいですね) 47 まとめ
48. この経験を活かして より良いKotlin移行を模索しながら 引き続き進めていきます！ 48
49. ご静聴ありがとうございました！ 49