More Related Content
Similar to Java エンジニアチームが始めやすい Scala コーディングスタイル #ichigayageek (20)
More from Kazuhiro Sera (20)
Java エンジニアチームが始めやすい Scala コーディングスタイル #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 プロジェクトとは
- 5. アジェンダ
• まず、私が関わる 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 待っています
- 11. アジェンダ
• まず、私が関わる OSS の宣伝を少しだけ..
• 重厚な設計を忘れて、まずシンプルに書き始める
• Java プログラマらしい整然としたプロジェクト
• 文でなく式であることを意識して if/else も使う
• 例外を否定するかどうかはスタンスをとる
• Future はスレッドプールを強く意識する
• Java モジュールの知識を活かす
• チームが目指したい Scala プロジェクトとは
- 12. アジェンダ
• まず、私が関わる OSS の宣伝を少しだけ..
• 重厚な設計を忘れて、まずシンプルに書き始める
• Java プログラマらしい整然としたプロジェクト
• 文でなく式であることを意識して if/else も使う
• 例外を否定するかどうかはスタンスをとる
• Future はスレッドプールを強く意識する
• Java モジュールの知識を活かす
• チームが目指したい Scala プロジェクトとは
- 13. 重厚な設計を忘れて、まずシンプルに書き始める
• 特に Java の人はあえて Scala を静的型を持つ Ruby と
捉えて、バランス感覚を養うとよい
• case class を value object の入れ物としてまず慣れる
(Java beans より楽!→パターンマッチの理解へ)
• 単純な結果のキャッシュはメソッド定義の代わりに
lazy val を使うだけで済むことも多い
• Scala は言語機能だけでテスタビリティを保てる
• val で定義したメンバも override できる
• 必ずしも DI の仕組みに頼る必要はない
- 16. アジェンダ
• まず、私が関わる OSS の宣伝を少しだけ..
• 重厚な設計を忘れて、まずシンプルに書き始める
• Java プログラマらしい整然としたプロジェクト
• 文でなく式であることを意識して if/else も使う
• 例外を否定するかどうかはスタンスをとる
• Future はスレッドプールを強く意識する
• Java モジュールの知識を活かす
• チームが目指したい Scala プロジェクトとは
- 17. Java プログラマらしい整然としたプロジェクト
• sealed を使うとき以外は 1 ファイル 1 モジュール
(class/companion or trait)
• public なメンバ・メソッドは型を明示する
• 適当にトップレベルに放り込まず package 階層を持つ
• 暗黙の型変換を使った既存 class 拡張を乱用しない(デ
フォルトで有効になる使い方を安易にやらない)
• 「とりあえず interface 定義」をやるなら中途半端にや
らない(実装を適切に分離/隠 する)
- 20. アジェンダ
• まず、私が関わる OSS の宣伝を少しだけ..
• 重厚な設計を忘れて、まずシンプルに書き始める
• Java プログラマらしい整然としたプロジェクト
• 文でなく式であることを意識して if/else も使う
• 例外を否定するかどうかはスタンスをとる
• Future はスレッドプールを強く意識する
• Java モジュールの知識を活かす
• チームが目指したい Scala プロジェクトとは
- 21. 文でなく式であることを意識して if/else も使う
• 再代入不可で var を書かない制約はさほど厳しくない
• メソッド・コードブロックが返すべき型を明示する
• ローカル変数でもコードブロックをうまく使う
• 返すべき型の値を返す if/else 式やパターンマッチ
(early return しない、else のない if を書かない)
• try/catch でも値を返せる特性を活かす
• Option(..).map(..).getOrElse(..) というイディオム
• チェインしすぎず、適度に名前をつける
- 24. アジェンダ
• まず、私が関わる OSS の宣伝を少しだけ..
• 重厚な設計を忘れて、まずシンプルに書き始める
• Java プログラマらしい整然としたプロジェクト
• 文でなく式であることを意識して if/else も使う
• 例外を否定するかどうかはスタンスをとる
• Future はスレッドプールを強く意識する
• Java モジュールの知識を活かす
• チームが目指したい Scala プロジェクトとは
- 25. 例外を否定するかどうかはスタンスをとる
• Scala は Java と違ってチェック例外の仕組みがない
(理由:Open-Closed Principle に従う)
• 例外を保持しうるデータ型:Try、Either、Future
• 例外を否定した API と決めたなら徹底的にやる(Try/
Either/Future を返すメソッドが例外投げるのは最悪)
• 常に標準のデータ型である必要はなく、成功・失敗を
反映した結果オブジェクトを返してもよい
- 29. アジェンダ
• まず、私が関わる OSS の宣伝を少しだけ..
• 重厚な設計を忘れて、まずシンプルに書き始める
• Java プログラマらしい整然としたプロジェクト
• 文でなく式であることを意識して if/else も使う
• 例外を否定するかどうかはスタンスをとる
• Future はスレッドプールを強く意識する
• Java モジュールの知識を活かす
• チームが目指したい Scala プロジェクトとは
- 30. Future はスレッドプールを強く意識する
• 標準で提供される ExecutionContext.global は一つの
ForkJoinPool が裏で動いている
• 用途ごとにプールを分けた方がよければ implicit で渡す
ExecutionContext を自前で作って使い分ける
• Future と同期処理を包んだものを混ぜるときはただ型
を合わせるだけでなく、挙動を理解し想像する
• Future の中の同期処理がスレッドプールを浪費する
リスクはないか、そのプール設定は妥当か
- 33. アジェンダ
• まず、私が関わる OSS の宣伝を少しだけ..
• 重厚な設計を忘れて、まずシンプルに書き始める
• Java プログラマらしい整然としたプロジェクト
• 文でなく式であることを意識して if/else も使う
• 例外を否定するかどうかはスタンスをとる
• Future はスレッドプールを強く意識する
• Java モジュールの知識を活かす
• チームが目指したい Scala プロジェクトとは
- 34. Java モジュールの知識を活かす
• 目的を達成するために Java の既存コードを組み合わせ
ることは何ら問題ない
• 手元の既存コードの流用だけでなく JDBC など標準
規格、主要サービス提供 Java SDK の利用
• Java っぽくなるが、局所的に使えばよい(完全に
ラップするのはそれなりにコストがかかる)
• バイナリ互換問題から解放されるメリット
• Collection API 変換は JavaConversions ではなく
JavaConverters を使う(asScala で明示的変換)
- 38. アジェンダ
• まず、私が関わる OSS の宣伝を少しだけ..
• 重厚な設計を忘れて、まずシンプルに書き始める
• Java プログラマらしい整然としたプロジェクト
• 文でなく式であることを意識して if/else も使う
• 例外を否定するかどうかはスタンスをとる
• Future はスレッドプールを強く意識する
• Java モジュールの知識を活かす
• チームが目指したい Scala プロジェクトとは
- 39. チームが目指したい Scala プロジェクトとは
• 長くメンテしていきたい Scala プロジェクト? or 使い
捨てのプロジェクト?
• 一つのプロジェクトに専念? or 更新頻度のまちまちな
小さなアプリケーションを複数かけもち?
• 依存ライブラリがどんどん互換性崩してもコンパイル
エラーになるから大丈夫?
• 何でも Scala でやりたがる病..(皆かかります)
• 最近、自分の中で流行っている新しいスタイル..
• このプロジェクト、後任はどう思うか?
- 40. たまには精神論でも..
• チームの納得感 + 客観的な目線
• この発表のスタイルがしっくり来るチームもあれば、
ほとんど納得できないチームもあるはず
• 組織の中で排他的なチームをつくってしまうと、中
長期的には負債になる(みんなが追いつくべき?)
• Scala は楽しい、なぜなら・・
• 自分の好きなようにやっていて楽しい?
• チームで開発しやすいから楽しい?
• Scala にしてよかったと認識される状況とは?
- 41. まとめ
• 凝りすぎず、シンプルに書く
• Java プログラマ的美徳は Scala でも活きる
• 基本 return を書かない、全ては式
• 例外を保持するデータ型はその設計に慣れてから
• Future はマルチスレッドプログラミング
• Java を流用するのは全然アリです
• チームのための Scala コードを書く