Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

頑張りすぎないScala

6,128 views

Published on

https://d-cube.connpass.com/event/74106/

Published in: Software
  • Be the first to comment

頑張りすぎないScala

  1. 1. 頑張りすぎないScala Naoki Takezoe @takezoen BizReach, Inc
  2. 2. 自己紹介 竹添 直樹: @takezoen ビズリーチという会社でScalaを書いてます OSS開発や技術書の執筆などもしています
  3. 3. 関数型プログラミング in Scala 基本的には副作用を使った手続き型プログラミング言語 関数型言語由来の様々な機能を備えている for内包表記、暗黙的なモナド Scalaz、Cats、Slickなどの関数型ライブラリ どこまで関数型に寄せるか?という選択を迫られる プログラミングスタイルだけでなく、ライブラリやフレームワークの 選定から考慮しなくてはならない 難しそう!!!!
  4. 4. Scalaの学習曲線 学習時間 Scala力
  5. 5. Scalaの学習曲線 最初はみんな 初心者 学習時間 Scala力
  6. 6. Scalaの学習曲線 Scala力アップ!! 最初はみんな 初心者 学習時間 Scala力
  7. 7. Scalaの学習曲線 Scala力アップ!! 最初はみんな 初心者 後から入ってくる 人つらい!! 学習時間 Scala力 ハードルの高さ
  8. 8. こうあって欲しい(気持ちは理解できる) 学習時間 Java力
  9. 9. 振り返り 最初はみんなScala初心者だった 初期のメンバーが少しずつレベルアップしてくる 関数型プログラミングが取り入れられてくる 時代によってコードの傾向が違う 後から入ってくる人ほどつらくなってしまう
  10. 10. 振り返り Scalaはプログラマの成長にあわせてスタイルを変えられる 長期間、固定のチームで開発するのであればチームの成長にあ わせて変化していくことができる メンバーの増加・入れ替わりが激しい場合は変化が大きいとどん どんハードルが上がっていってしまう
  11. 11. でも、思い出してみて欲しい
  12. 12. Scala != 関数型プログラミング言語
  13. 13. Scalaはいろんな使い方ができる
  14. 14. 最初の一歩、こんな方針はどうでしょう そもそもScalaは副作用のある手続き型プログラミング言語であ り、モナドを意識せずに使えるように設計されている Scalaの便利な機能を使いつつ、関数型プログラミングに寄せす ぎないようにする
  15. 15. 例: これらを使うべきか?使わないべきか? ● var ● mutableコレクション ● return ● null ● 例外
  16. 16. var
  17. 17. varとvalの違い 変数宣言 val name = "Naoki Takezoe" // 再代入不可能 var name = "Naoki Takezoe" // 再代入可能 Scalaでは一般的にvalの使用が推奨されている
  18. 18. varを使いがちなケース ループ処理などでフラグやアキュムレータに使いがち takeWhileやfoldLeftなどで代用可能だが取っつきづらい var line = reader.readLine() while(line != null) { ... line = reader.readLine() }
  19. 19. varの使用は禁止するべきか? valにできるものはvalにするべき メソッド内での利用であれば許容してもよいのでは? 最初はJavaでfinalをつけるかどうかくらいの感覚で使い分けるの がよさそう なるべくvalを使用するよう啓蒙していく
  20. 20. mutableコレクション
  21. 21. Scalaのコレクション Scalaにはimmutableなコレクションとmutableなコレクションが ある 基本的にはimmutableなコレクションが推奨されている // immutableなシーケンス val langs = Seq("Java", "Scala", "Kotlin") // mutableなシーケンス import scala.collection.mutable.ListBuffer val langs = ListBuffer("Java", "Scala", "Kotlin")
  22. 22. mutableコレクションを使いがちなケース ループしながら詰め替えるような処理で使いがち val list = ... val map = mutable.Map("some" -> 0, "none" -> 0) list.foreach { x => if (x.nonEmpty) { map.put("some", map("some") + 1) } else { map.put("none", map("none") + 1) } }
  23. 23. mutableコレクションを禁止するべきか? メソッド内での利用であれば許容してもよいのでは? 戻り値として返す際にimmutableなコレクションに変換する なるべくimmutableなコレクションを使うよう啓蒙していく val map = list.groupBy(_.nonEmpty) .map { case (nonEmpty, values) => if(nonEmpty) "some" -> values.size else "none" -> values.size }
  24. 24. return
  25. 25. Scalaのreturnはちょっと特殊 Ealry returnやループ処理中からのreturnなどが使われがち def hello(name: String): String = { if(name.isEmpty) return "" ... } 戻り値の型を明記しないといけなくなる コンパイル後に例外(ControlThrowableのサブクラス)で実現さ れるケースがある
  26. 26. returnが例外で実装されるケース def hello(names: Seq[String]): String = { names.foreach { name => if(name.isEmpty){ return "" } } ... }
  27. 27. コンパイルされるとこんな感じ(イメージ) def hello(names: Seq[String]): String = { try { names.foreach(checkHelloArguments) } catch { case e: NonLocalReturnControl[String] => return e.value } ... } private def checkHelloArguments(str: String): Unit = { if(str.isEmpty) throw new NonLocalReturnControl[String]("") }
  28. 28. returnを禁止するべきか? 実際に問題になるケースは少ないので許容してもよいのでは そもそも例外をThrowableでキャッチするべきではない try { ... } catch { case NonFatal(t) => ... }
  29. 29. null
  30. 30. nullを使うべき理由はまるでない
  31. 31. nullの代わりにOption型を使う def findUser(id: Long): Option[User] = { val user = userDao.get(id) if(user == null){ None } else { Some(user) } }
  32. 32. nullの代わりにOption型を使う val user = findUser(id) user match { case None => ... // 存在しない場合の処理 case Some(user) => ... // 存在する場合の処理 }
  33. 33. Javaライブラリを使う場合は仕方ない 可能であれば前述の例のようにラップしてOptionに変換したイン ターフェースを用意するとよい
  34. 34. 例外
  35. 35. Scalaでの例外処理 例外は副作用なので関数型プログラミングでは好まれない 関数の実行結果としてエラーを表現できる型で返す ScalaにはEither[A, B]という型がある 正常な場合はRight[B] エラーの場合はLeft[A]
  36. 36. Eitherの使い方 def findUser(): Either[Exception, User] = { try { val user: User = ... Right(user) } catch { case e: Exception => Left(e) } }
  37. 37. Eitherの使い方 val result = findUser() // パターンマッチで結果を取り出す result match { case Right(user) => ... // 成功時の処理 case Left(e) => ... // エラー時の処理 }
  38. 38. ただし全部Eitherで返そうとすると問題も どこで例外が発生するかわからないので各所で変換が必要にな る(特にJavaライブラリを使っている場合) 中途半端にやると戻り値がEitherなのに例外もスローされる場合 があるという地獄のような状態になってしまう for内包表記やEitherTなどが登場してしまう
  39. 39. 例外を禁止するべきか? エラーを呼び出し元でハンドリングする必要がある場合はEither などエラーを表現できる型を使う そうでない場合は積極的に例外を使う方向に倒してしまってもよ いのでは?
  40. 40. 最終的にはケースバイケース これらはあくまでも判断の一例 プロダクトの方向性、今後のチーム運営も考えて決める チームのスキルが一様であればそれにあわせればよい Scalaで楽しくプログラミングして欲しい 最初はみんな初心者だった 関数型プログラミングに興味のある人だけでなく、 それ以外の人たちにもScalaを使って欲しい
  41. 41. とはいえ... Better Javaに留まるのであればKotlinなどの選択肢がある 手続き型のオブジェクト指向プログラミングから関数型プログラミ ングが地続きになっているのがScalaの特徴 Scalaのメリットを活かすには関数型プログラミングを積極的に取 り入れていくべき
  42. 42. 次回予告 教養としてのモナド
  43. 43. ご静聴ありがとうございました

×