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.

Java エンジニアチームが始めやすい Scala コーディングスタイル #ichigayageek

14,997 views

Published on

http://ichigayageek.connpass.com/event/18810/

Published in: Technology
  • Be the first to comment

Java エンジニアチームが始めやすい Scala コーディングスタイル #ichigayageek

  1. 1. Java エンジニアチームが始めやすい Scala コーディングスタイル 瀬良 和弘 @seratch_ja #ichigayageek
  2. 2. 自己紹介 • Scala を初めて触ったのは 2009 年 • ScalikeJDBC プロジェクトリード(2011∼) • Skinny Framework プロジェクトリード(2013∼) • Scalatra、json4s、Scalate メンテナ
  3. 3. はじめに • この発表の内容は「Java を得意とする Scala 初学者の プログラマ」を想定してそうした方々が馴染みやすそ うな一つのスタイルを紹介するものです • 既に世の中には様々な Scala のコーディングガイドが ありますので、そちらもご参照ください • Scala Style Guide • Databricks Scala Coding Style Guide • PayPal Scala Style Guidelines • Twitter's Effective Scala (ちょっと古い)
  4. 4. アジェンダ • まず、私が関わる OSS の宣伝を少しだけ.. • 重厚な設計を忘れて、まずシンプルに書き始める • Java プログラマらしい整然としたプロジェクト • 文でなく式であることを意識して if/else も使う • 例外を否定するかどうかはスタンスをとる • Future はスレッドプールを強く意識する • Java モジュールの知識を活かす • チームが目指したい Scala プロジェクトとは
  5. 5. アジェンダ • まず、私が関わる OSS の宣伝を少しだけ.. • 重厚な設計を忘れて、まずシンプルに書き始める • Java プログラマらしい整然としたプロジェクト • 文でなく式であることを意識して if/else も使う • 例外を否定するかどうかはスタンスをとる • Future はスレッドプールを強く意識する • Java モジュールの知識を活かす • チームが目指したい Scala プロジェクトとは
  6. 6. まず、私が関わる OSS の宣伝を少しだけ.. • ScalikeJDBC - シンプルな DB アクセスライブラリ、 GitHub スター数では Slick に次いで 2 位 • Skinny Framework - Rails に強く影響を受けた Web フ レームワークを中心としたプロジェクト、Scaffolding をはじめ必要なものは一通り っている • Skinny Micro New! - Skinny Framework 2 のコア部分を 切り出したマイクロフレームワーク、Sinatra 風の DSL で簡単に Scala で Web アプリを作りことができる • Scalatra、json4s、Scalate も PR 待っています
  7. 7. Skinny Micro はこれだけで動く
  8. 8. Servlet だから Future 使いづらいを過去のものに
  9. 9. ぜひお試しください(気に入ったら star を)
  10. 10. それでは、本題へ・・
  11. 11. アジェンダ • まず、私が関わる OSS の宣伝を少しだけ.. • 重厚な設計を忘れて、まずシンプルに書き始める • Java プログラマらしい整然としたプロジェクト • 文でなく式であることを意識して if/else も使う • 例外を否定するかどうかはスタンスをとる • Future はスレッドプールを強く意識する • Java モジュールの知識を活かす • チームが目指したい Scala プロジェクトとは
  12. 12. アジェンダ • まず、私が関わる OSS の宣伝を少しだけ.. • 重厚な設計を忘れて、まずシンプルに書き始める • Java プログラマらしい整然としたプロジェクト • 文でなく式であることを意識して if/else も使う • 例外を否定するかどうかはスタンスをとる • Future はスレッドプールを強く意識する • Java モジュールの知識を活かす • チームが目指したい Scala プロジェクトとは
  13. 13. 重厚な設計を忘れて、まずシンプルに書き始める • 特に Java の人はあえて Scala を静的型を持つ Ruby と 捉えて、バランス感覚を養うとよい • case class を value object の入れ物としてまず慣れる (Java beans より楽!→パターンマッチの理解へ) • 単純な結果のキャッシュはメソッド定義の代わりに lazy val を使うだけで済むことも多い • Scala は言語機能だけでテスタビリティを保てる • val で定義したメンバも override できる • 必ずしも DI の仕組みに頼る必要はない
  14. 14. サンプル例
  15. 15. サンプル例
  16. 16. アジェンダ • まず、私が関わる OSS の宣伝を少しだけ.. • 重厚な設計を忘れて、まずシンプルに書き始める • Java プログラマらしい整然としたプロジェクト • 文でなく式であることを意識して if/else も使う • 例外を否定するかどうかはスタンスをとる • Future はスレッドプールを強く意識する • Java モジュールの知識を活かす • チームが目指したい Scala プロジェクトとは
  17. 17. Java プログラマらしい整然としたプロジェクト • sealed を使うとき以外は 1 ファイル 1 モジュール (class/companion or trait) • public なメンバ・メソッドは型を明示する • 適当にトップレベルに放り込まず package 階層を持つ • 暗黙の型変換を使った既存 class 拡張を乱用しない(デ フォルトで有効になる使い方を安易にやらない) • 「とりあえず interface 定義」をやるなら中途半端にや らない(実装を適切に分離/隠 する)
  18. 18. 型の明示に IntelliJ IDEA が便利
  19. 19. 型の明示に IntelliJ IDEA が便利
  20. 20. アジェンダ • まず、私が関わる OSS の宣伝を少しだけ.. • 重厚な設計を忘れて、まずシンプルに書き始める • Java プログラマらしい整然としたプロジェクト • 文でなく式であることを意識して if/else も使う • 例外を否定するかどうかはスタンスをとる • Future はスレッドプールを強く意識する • Java モジュールの知識を活かす • チームが目指したい Scala プロジェクトとは
  21. 21. 文でなく式であることを意識して if/else も使う • 再代入不可で var を書かない制約はさほど厳しくない • メソッド・コードブロックが返すべき型を明示する • ローカル変数でもコードブロックをうまく使う • 返すべき型の値を返す if/else 式やパターンマッチ (early return しない、else のない if を書かない) • try/catch でも値を返せる特性を活かす • Option(..).map(..).getOrElse(..) というイディオム • チェインしすぎず、適度に名前をつける
  22. 22. サンプル例
  23. 23. サンプル例
  24. 24. アジェンダ • まず、私が関わる OSS の宣伝を少しだけ.. • 重厚な設計を忘れて、まずシンプルに書き始める • Java プログラマらしい整然としたプロジェクト • 文でなく式であることを意識して if/else も使う • 例外を否定するかどうかはスタンスをとる • Future はスレッドプールを強く意識する • Java モジュールの知識を活かす • チームが目指したい Scala プロジェクトとは
  25. 25. 例外を否定するかどうかはスタンスをとる • Scala は Java と違ってチェック例外の仕組みがない (理由:Open-Closed Principle に従う) • 例外を保持しうるデータ型:Try、Either、Future • 例外を否定した API と決めたなら徹底的にやる(Try/ Either/Future を返すメソッドが例外投げるのは最悪) • 常に標準のデータ型である必要はなく、成功・失敗を 反映した結果オブジェクトを返してもよい
  26. 26. サンプル例
  27. 27. サンプル例
  28. 28. サンプル例
  29. 29. アジェンダ • まず、私が関わる OSS の宣伝を少しだけ.. • 重厚な設計を忘れて、まずシンプルに書き始める • Java プログラマらしい整然としたプロジェクト • 文でなく式であることを意識して if/else も使う • 例外を否定するかどうかはスタンスをとる • Future はスレッドプールを強く意識する • Java モジュールの知識を活かす • チームが目指したい Scala プロジェクトとは
  30. 30. Future はスレッドプールを強く意識する • 標準で提供される ExecutionContext.global は一つの ForkJoinPool が裏で動いている • 用途ごとにプールを分けた方がよければ implicit で渡す ExecutionContext を自前で作って使い分ける • Future と同期処理を包んだものを混ぜるときはただ型 を合わせるだけでなく、挙動を理解し想像する • Future の中の同期処理がスレッドプールを浪費する リスクはないか、そのプール設定は妥当か
  31. 31. サンプル例
  32. 32. サンプル例
  33. 33. アジェンダ • まず、私が関わる OSS の宣伝を少しだけ.. • 重厚な設計を忘れて、まずシンプルに書き始める • Java プログラマらしい整然としたプロジェクト • 文でなく式であることを意識して if/else も使う • 例外を否定するかどうかはスタンスをとる • Future はスレッドプールを強く意識する • Java モジュールの知識を活かす • チームが目指したい Scala プロジェクトとは
  34. 34. Java モジュールの知識を活かす • 目的を達成するために Java の既存コードを組み合わせ ることは何ら問題ない • 手元の既存コードの流用だけでなく JDBC など標準 規格、主要サービス提供 Java SDK の利用 • Java っぽくなるが、局所的に使えばよい(完全に ラップするのはそれなりにコストがかかる) • バイナリ互換問題から解放されるメリット • Collection API 変換は JavaConversions ではなく JavaConverters を使う(asScala で明示的変換)
  35. 35. サンプル例
  36. 36. サンプル例
  37. 37. サンプル例
  38. 38. アジェンダ • まず、私が関わる OSS の宣伝を少しだけ.. • 重厚な設計を忘れて、まずシンプルに書き始める • Java プログラマらしい整然としたプロジェクト • 文でなく式であることを意識して if/else も使う • 例外を否定するかどうかはスタンスをとる • Future はスレッドプールを強く意識する • Java モジュールの知識を活かす • チームが目指したい Scala プロジェクトとは
  39. 39. チームが目指したい Scala プロジェクトとは • 長くメンテしていきたい Scala プロジェクト? or 使い 捨てのプロジェクト? • 一つのプロジェクトに専念? or 更新頻度のまちまちな 小さなアプリケーションを複数かけもち? • 依存ライブラリがどんどん互換性崩してもコンパイル エラーになるから大丈夫? • 何でも Scala でやりたがる病..(皆かかります) • 最近、自分の中で流行っている新しいスタイル.. • このプロジェクト、後任はどう思うか?
  40. 40. たまには精神論でも.. • チームの納得感 + 客観的な目線 • この発表のスタイルがしっくり来るチームもあれば、 ほとんど納得できないチームもあるはず • 組織の中で排他的なチームをつくってしまうと、中 長期的には負債になる(みんなが追いつくべき?) • Scala は楽しい、なぜなら・・ • 自分の好きなようにやっていて楽しい? • チームで開発しやすいから楽しい? • Scala にしてよかったと認識される状況とは?
  41. 41. まとめ • 凝りすぎず、シンプルに書く • Java プログラマ的美徳は Scala でも活きる • 基本 return を書かない、全ては式 • 例外を保持するデータ型はその設計に慣れてから • Future はマルチスレッドプログラミング • Java を流用するのは全然アリです • チームのための Scala コードを書く

×