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

Transcript of "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 コードを書く