Scala関西 Summit2016の翌日、京都のはてなさんオフィスに伺わせていただき弊社とはてなさんの合同Scala勉強会を開催しました。
今回はクローズドな勉強会ということで普段あまり外には出せないようなリアルな悩みなどもご相談させていただいたのですが、当日の内容を可能な範囲でまとめてみたいと思います。
Scalaの利用状況について
はてなさんでScalaを採用しているのは3プロジェクト、社内でScalaを書けるエンジニアは10人ほど、フレームワークはPlay + SlickもしくはScalatra + Slickとのことですが、最近のプロジェクトではSlickはDSLを使わず生SQLを書いているそうです。WebフレームワークはFinchも検討されたそうなのですが、生産性に問題があるという判断で採用には至らなかったとのことでした。
弊社でScalaを使っているのは2プロジェクトですが、それぞれのプロジェクトの規模ははてなさんより大きめで、社内でScalaを書けるエンジニアは30人ほどです。フレームワークは基本的にPlay + Slickを使っていますが一部ではScalikeJDBCも使い始めています。
また、はてなさんではPerlはもちろんのこと、小さなサブシステムであればGoで書くという選択肢もあり、ScalaはDDDがやりやすい抽象度の高い言語として採用されているとのことで、この点についてはJVM言語をコアコンピタンス（一部にはRailsを使っているプロジェクトもありますが）としている弊社のスタンスとは少し異なるものでした。
開発環境について
両社ともに開発環境はMacBook Proがメインのようです。IDEがIntelliJメインであること、一部にEmacsやvimで開発している人がいるのも同じでしたw
Scalaのコンパイル速度について、はてなさんでは以下のように様々な工夫をされているそうです。
弊社ではマイクロサービス化によって1プロジェクトをコンパクトにしたり、一部のサービスではマルチプロジェクト化を進めていたりしますが、ライブラリやコーディングにおけるルールまでは定めていません。コンパイル速度を気にしてコードを書くとScalaの言語としてのパワーがスポイルされてしまう部分もあると思うのでなかなか悩ましいところです。
また、普段はインクリメンタルコンパイルでコンパイル範囲を限定することでそれなりのテンポで作業できていても、ブランチ切り替えの際に依存関係の更新やフルビルドをしなくてはならないケースはかなりきついです。弊社では、大きなプロジェクトを触っているチームではブランチ毎にリポジトリをクローンすることでなるべくフルビルドをしなくても済む形で作業しているメンバーもいます。
なお、弊社はJavaからScalaという流れだったのであまり気になりませんでしたが、はてなさんではPerlからScalaという流れだったので「デプロイが気軽にできなくなった」という点も違いとしてあげられていました。
Scalaのコードスタイルについて
はてなさんではScalazなどの関数型ライブラリは使わないようにしているそうです。弊社でもScalazは使っているものの、頻繁に利用するのは一部の機能に限られているので必要なものだけ自作して使うほうがいいのかも、という気がしています。
また、弊社ではメンバー間のScala力の差などにより、コードレビューが特定の人に集中してしまったりということがあります。また、レビューも表層的なレビューになってしまったり、正直なところテストもあまり書けていなかったりするのですが、はてなさんはPerlのチームも含め昔からテストを書いたりレビューをしっかりやる文化が根付いているとのことでした。
もちろんいたずらに完璧を求めるのではなく、明らかに修正するべきコードでも他に優先すべきことがあったり、直す労力が見合わない場合はリファクタリングを後回しにしたり、より簡単な方法で逃げるという判断をされているそうなのですが、このあたりは人によって閾値が違うと軋轢を生んでしまう可能性もあるので会社なりチームなりで価値観が共有されていることが重要だと思います。弊社ははてなさんと比べると比較的新しいメンバーも多いので、こういった部分には課題感があります。
おわりに
はてなさん、休日にも関わらずありがとうございました。勉強会後の懇親会でお話しさせていただいた内容も含め、日常の業務はもちろんのこと今後のScalaの普及展開に関しても様々なヒントを得ることができました。Scalaが今後もお互いにより良いサービスを作っていく上での助けになればと思います！
