Scala関西Summit 2018参加レポート

かたいなか

2018.11.12

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、かたいなかです。

2018年11月10日から11月11日の二日間にわたってScala関西Summit 2018が開催されました。

天満研修センターにて開催された1日目に参加してきましたので参加したセッションの内容をレポートします。

長期的なメンテナンスの必要なScala製システムにおいて気をつけるべきこと

竹添直樹さん

スライドが公開されていないようだったため、聴講時のメモをもとに内容をリポートします。

長期メンテナンスを難しくする要因

Scalaの長期的なメンテナンスを難しくする要因としてはプログラミングスタイルとアップグレードの2つの要因がある。

プログラミングスタイル

Scalaは関数型に寄せてもオブジェクト指向に寄せてもコードを書ける。プロダクトが続いていくとコードを書く人のレベルが上ってコードを書く方法がどんどんアドバンストになってしまうことが多い。

この問題については、このスタイルが良いというような一般論にはできないため、場合によりけりで会社組織としてどういったスタイルで書くべきかの指針の合意を取る必要がある。人が抜けたときに問題にならないようにScalaに限らず技術選定は組織として行うべき。

一度特定の技術にマイナスのイメージが付いてしまうと払拭するのは難しい。

新しく入ってきた人にもわかりやすいため、極端に関数型に寄せすぎず、手続き型オブジェクト指向のなかに関数型の便利な機能を取り入れていくのが良いのではないか。

なぜJavaやKotlinではなくScalaを使うのか理由をきちんと考えておくべき。

アップグレード

3種類のアップグレード

framework
Scala
Java

一つを上げる必要が出ると芋づる式に他の2つもアップグレードする必要があることが多い。

ケース１：Scala2.12へのアップグレードの時

PlayやSlickのも同時にアップグレードが必要になり、APIの大きなbreaking changeに対応しないといけなくなった。

PlayはGuiceでDIするように・・・
SlickはIOモナドに・・・

ケース２：Java8へのアップグレード

Scalaとフレームワークの両方のバージョンアップが必要になった。

一気に複数バージョン上げる必要がでてので大変だった。

新しいバージョンへのアップグレードはきちんと追従していかないとのちのちとても大変。マイグレーションガイドがでているPlayでも大変なので普通のライブラリだともっとと大変なはず。ソースコードも見ないといけない場合も。

フレームワークが後方非互換な変更することが多い

Play
- Play1からPlay2で別物のフレームワークに
- PlayのDI導入でGuiceを使うように
- GlobalContextの廃止
Slick
- ScalaQueryからSlickという名前の変更でAPIはあまり変わらなかったがパッケージ名は変わった
- IO Monadを導入してしまった
Spray
- Akka HTTPが後継になったので移行する必要が
ある程度は互換性が意識されているが細かいところが違ってどう直せばいいか困るケースがある

解決策

Scalaの文化なので気にしない
最近は安定してきた。ScalaにしてもPlayにしても大きなbreaking changeが出なくなった。エコシステム全体が安定してきている
JavaのフレームワークをScalaでやるのが合理的な解決策になるかもしれない。一つの選択肢。
Scala3で新機能が導入されてしまう・・・フレームワーク作る人の性質として新しい機能が出ると使いたくなるため、非互換な変更が多くなってしまうのではないか。

バイナリ互換性

Scalaは2.12.1から2.12.2のようなマイナーバージョンアップではバイナリ互換だが、2.12から2.13のようなメジャーバージョンアップではバイナリ非互換の変更を含む。

フレームワークも過去のバージョンでコンパイルされたものが動かなくなるので、メジャーバージョン対応するには新しいバージョンをリリースしないといけない。

ScalaのライブラリのArtifactIdにはScalaのバージョンが含まれているのはそのため。

新しいScalaバージョンでリリースされていない場合、build.sbtで依存するライブラリのScalaバージョンのサフィックスで無理やり過去のバージョンを指定することもできる。大きなライブラリでは動かないことのほうが多いが小さなライブラリでは動く場合も・・・保証はない・・・・。

一つのライブラリで複数のScalaバージョンを使用してビルドしたいときはクロスビルド。

バイナリ非互換問題　

使う側からすると、JavaはJavaのライブラリ、昔のJavaのバージョンで作られたJarファイルが今も動くが、Scala自体に後方非互換性があるのでメンテナンスされていないライブラリが将来のバージョンで利用できなくなる可能性。

長期のメンテナンスしやすくするには

依存関係を減らすべき Syntax Sugar系のはなるべくやめるべき小さいライブラリであれば外部のメンテされるかわからないライブラリに依存するよりは自分で作ることも選択肢
有名なライブラリをなるべく選ぶアクティブすぎると変更が激しくて追従が大変になることも
Javaでライブラリを作るのも一つの選択肢。クロスビルド等を考える必要がない。 Scalaである必要がないライブラリはJavaでつくるのが良い選択肢になる。

circeから学ぶ Generic Programming 入門

森本真一さん

Circeでimportするだけでcase classに対してJsonのデコードが行える仕組みの実装を通して、型クラスのわかりやすい説明や、Shapelessを利用した型クラスのインスタンスの自動導出の仕組みまで、GenericProgrammingの基礎の部分がとてもわかりやすく説明されていました。

個人的にShapelessをきちんと勉強したことがなかったのですが、GenericProgrammingによってボイラープレートの削減ができることに強烈な刺激を受け、きちんと学んでみたいと思いました。最後に紹介されていたThe Type Astronaut's Guide to Shapelessの資料を読み込みたいです。