Upgrade to Pro — share decks privately, control downloads, hide ads and more …

行こう to Kotlin

行こう to Kotlin

第6回Kotlin勉強会 @ Sansan で発表した内容です。

mintcreamcat

June 30, 2017
Tweet

Other Decks in Technology

Transcript

  1. どのように移行しているか① • Androidアプリを1人で担当(その他スクラムマスターも兼任) • 2016年8月から開始 • 最初の2〜3ヶ月は少しずつ試しに書きながら様子を見る ◦ 新技術導入なので若干慎重に ▪

    画面を書き換えたりはせずに、小さいコンポーネントを Kotlinで書いて見る • 一番最初にやったのはボタンの共通化 ◦ 同時に新しいアーキテクチャの検討を行う ▪ MVVMパターンを採用 ▪ RxJava + 関数型プログラミングを導入 ▪ 極力nullを使わない
  2. どのように移行しているか② • アーキテクチャが固まったら ◦ 新規に実装するコードは原則 Kotlinで書く ◦ 既存のJavaコードの修正も、極力 Kotlinの新しいファイルに切り出す ◦

    特定の画面をまるごと書き換える ▪ 利用者数が少ない画面から初めてみる ▪ 徐々に重要な画面も書き換えていく • 大きな変更のタイミングで工数を確保して既存部分を一気に作り直す
  3. 現状 • 移行開始から半年で、ソースコードの行数ベースではJava:Kotlin=1:1ぐらい • 画面数ベースではJava:Kotlin = 3:7 ぐらい ◦ Kotlinの方が行数あたりの機能実現量が大きい

    (*1) → 高生産性(*2)  ✳ 1. アーキテクチャ見直しによる効率アップや機能削減の影響も含む ✳ 2. ソースコードの行数で言語を語るのはナンセンスなので、あくまで参考値ということで
  4. 感想 • AndroidStudioでKotlinは快適に書けます ◦ コード補完が動き、リファクタリングもできる • JavaとKotlinのコードは問題なく共存できる ◦ KotlinのコードをJavaから呼び出すと冗長な記述になることがある •

    KotlinプラグインのJava->Kotlin変換機能が強力 • Kotlinの生産性の高さが、プロダクトに良い影響を与えている ◦ 機能改修・追加の速度が上がった ◦ 品質が向上 ▪ 特にNPEをかなり減らせた
  5. 技術戦略上の観点 • 新技術への移行は常にリスクが伴う • Objective-C -> Swift移行時の経験 ◦ IDEのサポートが十分でない ◦

    言語仕様変更 ◦ 旧言語と新言語間のやりとりの面倒さ • Kotlin移行は(経験した限りでは)リスクが非常に小さい