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

1. Java エンジニアチームが始めやすい Scala コーディングスタイル瀬良和弘 @seratch_ja #ichigayageek

2. 自己紹介 • Scala を初めて触ったのは 2009 年 • ScalikeJDBC プロジェクトリード（2011∼） • Skinny Framework プロジェクトリード（2013∼） • Scalatra、json4s、Scalate メンテナ

3. はじめに • この発表の内容は「Java を得意とする Scala 初学者のプログラマ」を想定してそうした方々が馴染みやすそうな一つのスタイルを紹介するものです • 既に世の中には様々な Scala のコーディングガイドがありますので、そちらもご参照ください • Scala Style Guide • Databricks Scala Coding Style Guide • PayPal Scala Style Guidelines • Twitter's Effective Scala (ちょっと古い)

4. アジェンダ • まず、私が関わる OSS の宣伝を少しだけ.. • 重厚な設計を忘れて、まずシンプルに書き始める • Java プログラマらしい整然としたプロジェクト • 文でなく式であることを意識して if/else も使う • 例外を否定するかどうかはスタンスをとる • Future はスレッドプールを強く意識する • Java モジュールの知識を活かす • チームが目指したい Scala プロジェクトとは

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. Skinny Micro はこれだけで動く

8. Servlet だから Future 使いづらいを過去のものに

9. ぜひお試しください（気に入ったら star を）

10. それでは、本題へ・・

13. 重厚な設計を忘れて、まずシンプルに書き始める • 特に Java の人はあえて Scala を静的型を持つ Ruby と捉えて、バランス感覚を養うとよい • case class を value object の入れ物としてまず慣れる（Java beans より楽！→パターンマッチの理解へ） • 単純な結果のキャッシュはメソッド定義の代わりに lazy val を使うだけで済むことも多い • Scala は言語機能だけでテスタビリティを保てる • val で定義したメンバも override できる • 必ずしも DI の仕組みに頼る必要はない

14. サンプル例

15. サンプル例

17. Java プログラマらしい整然としたプロジェクト • sealed を使うとき以外は 1 ファイル 1 モジュール（class/companion or trait） • public なメンバ・メソッドは型を明示する • 適当にトップレベルに放り込まず package 階層を持つ • 暗黙の型変換を使った既存 class 拡張を乱用しない（デフォルトで有効になる使い方を安易にやらない） • 「とりあえず interface 定義」をやるなら中途半端にやらない（実装を適切に分離/隠する）

18. 型の明示に IntelliJ IDEA が便利

19. 型の明示に IntelliJ IDEA が便利

21. 文でなく式であることを意識して if/else も使う • 再代入不可で var を書かない制約はさほど厳しくない • メソッド・コードブロックが返すべき型を明示する • ローカル変数でもコードブロックをうまく使う • 返すべき型の値を返す if/else 式やパターンマッチ（early return しない、else のない if を書かない） • try/catch でも値を返せる特性を活かす • Option(..).map(..).getOrElse(..) というイディオム • チェインしすぎず、適度に名前をつける

22. サンプル例

23. サンプル例

25. 例外を否定するかどうかはスタンスをとる • Scala は Java と違ってチェック例外の仕組みがない（理由：Open-Closed Principle に従う） • 例外を保持しうるデータ型：Try、Either、Future • 例外を否定した API と決めたなら徹底的にやる（Try/ Either/Future を返すメソッドが例外投げるのは最悪） • 常に標準のデータ型である必要はなく、成功・失敗を反映した結果オブジェクトを返してもよい

26. サンプル例

27. サンプル例

28. サンプル例

30. Future はスレッドプールを強く意識する • 標準で提供される ExecutionContext.global は一つの ForkJoinPool が裏で動いている • 用途ごとにプールを分けた方がよければ implicit で渡す ExecutionContext を自前で作って使い分ける • Future と同期処理を包んだものを混ぜるときはただ型を合わせるだけでなく、挙動を理解し想像する • Future の中の同期処理がスレッドプールを浪費するリスクはないか、そのプール設定は妥当か

31. サンプル例

32. サンプル例

34. Java モジュールの知識を活かす • 目的を達成するために Java の既存コードを組み合わせることは何ら問題ない • 手元の既存コードの流用だけでなく JDBC など標準規格、主要サービス提供 Java SDK の利用 • Java っぽくなるが、局所的に使えばよい（完全にラップするのはそれなりにコストがかかる） • バイナリ互換問題から解放されるメリット • Collection API 変換は JavaConversions ではなく JavaConverters を使う（asScala で明示的変換）

35. サンプル例

36. サンプル例

37. サンプル例

39. チームが目指したい Scala プロジェクトとは • 長くメンテしていきたい Scala プロジェクト？ or 使い捨てのプロジェクト？ • 一つのプロジェクトに専念？ or 更新頻度のまちまちな小さなアプリケーションを複数かけもち？ • 依存ライブラリがどんどん互換性崩してもコンパイルエラーになるから大丈夫？ • 何でも Scala でやりたがる病..（皆かかります） • 最近、自分の中で流行っている新しいスタイル.. • このプロジェクト、後任はどう思うか？

40. たまには精神論でも.. • チームの納得感 + 客観的な目線 • この発表のスタイルがしっくり来るチームもあれば、ほとんど納得できないチームもあるはず • 組織の中で排他的なチームをつくってしまうと、中長期的には負債になる（みんなが追いつくべき？） • Scala は楽しい、なぜなら・・ • 自分の好きなようにやっていて楽しい？ • チームで開発しやすいから楽しい？ • Scala にしてよかったと認識される状況とは？

41. まとめ • 凝りすぎず、シンプルに書く • Java プログラマ的美徳は Scala でも活きる • 基本 return を書かない、全ては式 • 例外を保持するデータ型はその設計に慣れてから • Future はマルチスレッドプログラミング • Java を流用するのは全然アリです • チームのための Scala コードを書く

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

More Related Content

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