こんにちは。あたぎです。
今日は、先日行われたアジア最大のScalaカンファレンスであるScalaMatsuri2017の参加レポートです。
ぐるなびでは基本的にPHPを用いて開発を行うことが多いですが、私の携わる レストランの検索機能を始めとしていくつかのプロジェクトでは部分的にScalaの導入を始めており、今回も検索機能に携わるメンバー数名で参加してきました。
私自身、まだそれほどScala経験豊富ではないので、若干理解が浅いところもあるかもしれませんが、以下はいくつか参加したセッションのうち、印象に残っているものの簡単なまとめと所感になります。
Readable Scala
先述の通り、ぐるなびではScalaは部分的に使い始めていますが、Scalaエンジニアの数は、PHPのエンジニアに比べてはるかに少数派です。 PHPなど他言語のエンジニアと話している中で、「Scalaって、なんだか複雑で読みづらくない…？」という声を聞くことがたまにあります。 Scalaのどの辺りが「読みづらい」か、というのは人によってまちまちだと思いますが、このセッションでは、「読みやすい(Readable)」コードを、名著「リーダーブルコード」に則り、「どれだけ早くそのコードを理解できるか」と定義し、一見複雑に見えるScalaのコードが、Scalaの作法に則って書かれているものである限り、実は読みやすい(Readable)ものである、というお話でした。
特にScalaに関して「読みづらい」と槍玉に挙げられる三つの文法について解説が行われていました。
記号識別子について
時々メソッド名などに記号が使われる事について。読み手が記号の意味について理解さえしていれば、メソッド名等を英文で定義するよりも、記号の方がコードを早く理解することが可能ということでした。例えば、乗算を「a * b」と書くのと、「a.multiply(b)」と書くのでは、どちらが「早く理解できる」か。
Implicit Parameters(暗黙のパラメータ)について
可読性という点でこちらも批判に晒されることの多い部分ですが、そもそもImplicit Parametersの目的は、「何(What)を実現したいか」と「どうやって(How)実現したいか」を分離すること。それによって「何(What)」が端的に表され、コードがReadableにできるという話でした。逆に言えば、「何(What)」と「どうやって(How)」を分離しないようなImplicit Parametersの用い方は、コードをReadableではなくしてしまうので注意が必要ということです。
Implicit conversions(暗黙の型変換)について
Implicit conversionsの目的は、定義を変更できないクラスにメンバを追加すること。何かのクラスを拡張したい時に、そのクラスの定義を変更できない場合は、何かしらのユーティリティを定義する事になりますが、ユーティリティ経由で操作するよりは、Implicit conversionsでメンバを追加した方が、読みやすさは向上するということでした。
所感としては、記号識別子についてもimplicit修飾子にしても、確かにReadableである事に寄与しているかと思うのですが、Readableであるためには、開発者間でScalaの様々な思想が前提として共有されている必要があって、これからScalaエンジニアを社内で育成する場合、それをどうやったら伝達いけるか、というところに課題感を持ちました。
スライドはこちら
Readable Scala／登壇者：中村学（がくぞ）さん
新サービスをゼロから開発してローンチするのに大切だった3つのこと
Twitter社の事例。 Railsで作られていたモノリシックなアプリケーションを、マイクロサービスに分割していく中で得られた知見の紹介でした。 モノリシックなアプリケーションをサービス単位に分解してScalaで書き直し、個々のサービスを一つの関数としてみなし、非同期に呼び出して、再度合成するという、「関数的な」アーキテクチャを採用したという話です。
同日に行われたChatWork社の事例についてのセッションもそうですが、サービスのスタート当初にLLでスピード優先で作られた巨大なアプリケーションが、技術的負債によって、性能やメンテナンス性の限界に達して、マイクロサービスの形に作り直していく、というのは、ぐるなびのサービスも同様の問題を抱えているため、興味深い内容でした。
技術的負債を増やさないためには？ という部分が特に印象に残っています。
技術的負債が増える原因を、システムに関して何かしら間違った想定をもとに開発してしまうこと（おそらくそれは机上の空論に基づいて開発に着手してしまう事だと思うのですが）として、それを避けるために、プロダクトマネージャーからの新しい要求に答える際には、なるべく早く、上流から下流までのすべてのサービスをつなげてとにかく動かし、想定をしなければならない事をなるべく減らす、というアプローチを取っているという話が印象に残ってます。
きっとそういった形の一種のプロトタイピングは、手が早い人が多いからできるんだろうな、とも思います。チーム全体としてどうやって生産力を高めているのか、もっと深く聴いてみたいセッションでした。
スライドはこちら
新サービスをゼロから開発してローンチするのに大切だった3つのこと／登壇者：Yoshimasa Niwaさん
メタメタにしてやんよ。(メタプログラミングもしくは Shapeless のすすめ)
ちょっとしたフレームワークのようなものを作ろうとして、Scalaのマクロと格闘したことがあるので、個人的に興味深いセッションでした。
ボイラープレートを減らすこと等を目的にしてメタプログラミングを行う時に、scala.metaなどを使うのも良いですが、場合によってはShapelessというライブラリを使うとよりスマートにできる、という話でした。 Shapelessは、うまく使えば確かにボイラープレートを減らすことができるのだと思いますが、個人的には「ここが使いどころだ！」という勘を身につけるまでが時間かかりそうな気がしました。
まずはこちらのガイドを（英語ですが）頑張って読むところから始めようと思います。
［GitHub］underscoreio/shapeless-guide
スライドはこちら
メタメタにしてやんよ。(メタプログラミングもしくは Shapeless のすすめ)／登壇者：Chris Birchallさん
Serverless ArchitectureをScalaで構築するぞ
Serverless Architectureについての論議が盛んですが、Scalaで実現するにあたって良いプラクティスはあるのかと、かねてから疑問があったので個人的に興味深いセッションでした。
特定のプラットフォームへのロックインを避けるために、何かしらの形でドメインロジックをプラットフォームに依存するコードと切り離す必要があるのかな、とは漠然と考えていましたが、このセッションではヘキサゴナルアーキテクチャによってそれを実現したという実例を聞けて参考になりました。
スライドはこちら
Serverless ArchitectureをScalaで構築するぞ／登壇者：藤井善隆さん
まとめ
先述の通り、ぐるなびはまだScalaに関してはそれほど多く知見があるわけでなく、今回一緒に参加したメンバーも実務経験一年未満の人間が多かったのですが、そんな中で、この道の先駆者の方々の話を聞けて非常に勉強になりました。
26日には板前さんがその場で握ったお寿司がでました
セッション自体も興味深いのですが、当日は美味しいお弁当が出たりお寿司が出たり、至れりつくせりで、非常に楽しい時間を過ごすことができました。
まさにScalaのお祭りですね。来年もぜひ参加したいと思います。
お知らせ
ぐるなびでは一緒に働く仲間を募集しています。