【Scala福岡2017 レポート】Backlog が一体いつから Scala を遣っていないと錯覚していた？ ~Java から Scala への移行~ #scalafukuoka

はじめに

こんにちは！おおはしりきたけです！今回は、7月29日(土）に開催された、「Scala福岡2017」に参加しました。3Fで行われたセッションは、こちらに纏まっています。私は7Fで開催されたヌーラボ谷本さんと松本さんのセッションレポートを書かせていただきます。

Backlog が一体いつから Scala を遣っていないと錯覚していた？ ~Java から Scala への移行~

スピーカーは、株式会社ヌーラボの谷本陽介さんと松本裕二さんです。

セッション概要は以下です。

Scala ヌーラボではプロジェクト管理ツール Backlog を Java から Scala / Play Framework へ段階的に移行しようとしています。 10年間にわたって Java で開発されてきたプロダクトを、ユーザーへの影響をできるだけ小さくしつつ、 Scala へと段階的に移行させていく取り組みについて Backlog Play チームの2人がお話しします。

谷本が Play フレームワークへの段階的な移行の方法と手順について、 松本が Scala 初心者として、ソースコードを Java から移植したことについてお話しします。

Play化プロジェクトとは

• BacklogのWebアプリケーション部分をSeasar + JavaからPlay + Scalaにする
• アクション数は400~500
• 今の予定としては、後1年程度かかる見込み
• ただし、機能追加とバグ修正は通常通り行う
• つまり、実運用しながら、長期間掛けてユーザーから見えない実装をごそっと入れ替えるプロジェクト
• Backlogチーム内用語としてはTomcat版とPlay版がある

なぜ移行するの？

• 理由は、Backlogの成長を加速させるため
• 移行タスクとしてSeasarからの卒業とリファクタリング
• Seasarからの卒業
  • SeasarプロジェクトのプロダクトはEOLになった
  • よりモダンなプロダクト・フレームワークに乗り換える
• リファクタリング
  • 10年以上の歴史における数多の修正で複雑化しているのでメンテナンス性を向上

なぜScala + Play Framework？

• Javaよりモダンな言語
• 型推論やパターンマッチ
• 静的型付け言語（Backlog開発者は静的型付け言語の方が得意な人が多い）
• 既存知識から大きく離れない
• JVM言語間は相互呼出ができる
• 一部は既存コードのままにしてScalaからJavaを呼び出している

Backlog API v2 の実績

• ScalaとPlayを使ってDDDで設計
• Domain層は共通で使える

移行方法（ボツ案1)

• 全てのアクションを移植が完了してから、入れ替える
  • Tomcat版とPlay版の両方に機能追加とバグ修正が必要

移行方法（ボツ案2）

• Javaから呼び出されるメソッドを少しずつScalaに移植
  • うまくいきそうに見えるが、実際にはJavaとScala間でEntityの相互変換するコードが必要
  • 全てのEntity（100個以上）ある
  • ScalaはDDDだがJavaはDDDじゃない
  • 完了時に捨てるとわかっているコードなので頑張って書くのはツライ

採用した移行方法

• 機能単位を作りきってNginxでアクセスをPlay版に振り分ける
• ただし、Sessionを共有する仕組みが必要
  • Redisを使って実装

採用理由

• ボツ案1に近いが、ドックフーディングもしやすいし、ユーザーへの影響が抑えやすい
• 完了後に捨てるコードがほぼ無い
• コードベースが完全に別れるため、Tomcat版の設計に引きづられることもない

JS&CSS

• DOM構造の移植が正しくできていれば、ほぼ修正は必要ない
  • 以下のツールを2つ作った
    • 旧ViewテンプレートからTwirlのツール
    • Tomcat版とPlay版の両方にアクセスしてDOMを比較するツール

利点

• Toｍcat版のリリースとPlay版のリリースを切り離して考える
• 移植が正しくできていなくてもNginxの設定を戻せばいい
• Dashboradの移植は、実際4度戻した

課題

• Play化チームの移植と別チームの機能追加とかが平行している画面は差異がでやすい
• コードベースが別れているのでコンフリクトしないため気づきにくい
• 全画面に及ぶ変更はTomcat版とPlay版の両方に変更が必要でコストが高い
• 今のところ、早く終わらせるくらいしか解決策は無さそう

Scala初心者がJava→Scalaへ移行したお話

Scalaのお勉強の話

• 社内勉強会をする
• ドワンゴのScala研修テキストを週一で輪講
• さるでもわかるScalaを開催（ヌーラボ本社/隔週月曜）
• 新入社員研修で使う社内ツールをPlay、Akka、WSで作った
• BacklogのAPIは既にScala + Playで動作しているので実務で経験する

実際のはまりどころ

• 他の言語との細かい文法の違い [T] ⇔ <T>とかOpriton⇔Optional
• implicit class
• for式
  • for comprehension

BacklogをScala/playへ移行させる話

Scala + Playへの移行方針

• JavaScriptは変えない（DOM構造が同じだから）
• アクションごとにルーティング設定を書き換える
• アクションをScalaに書き換える
• テンプレートを書き換える

Coreの移行

• ApplicationServiceにメソッドを生やす
• Repository経由でデータを取り出す

よかったこと

• 簡潔に書ける（ただし、すべての人に読みやすいわけではない）
• コレクションのAPIが豊富
• パターンマッチング

むずかしいところ

• 書き換えに筋力がいる
• ソースを読み解く
• Javaの古いライブラリ
• Scalaらしく書く
• DDDらしく書く

まとめ

• メンテナンス性を向上させて、開発を加速させるためにやっている
• JS + CSSとかはほとんどいじらない
• アクション単位で書き換えている

Q&A

• Q：移行プロジェクトは何人でやっているか？
  • A：今は3名でやっているが、今後増やしていきたい。増やします！by 縣さん
• Q：移行の単位をどのように決めているか？
  • A：ユーザーが使うところから移行を進めている

まとめ

Backlogは既に10年使われているサービスで、これからのさらなる発展のためにPlay + Scalaへの移行を決めたとのことでした。移行の注意ポイントや、実践したノウハウをお聞き出来たので、非常に参考になりますた。ありがとうございました！