新サービスUniposに新言語elmを導入しました！

Fringe81エンジニアの関(@jshosomichi)です。主にフロントエンドの開発を担当しています。

先日、Fringe81は新規事業、Unipos(ユニポス)の正式版をリリースしまして、このサービスは我々が持つ発見/賞賛する文化をWebサービスとして実現し、強い組織を作っていくという、開発背景として思い入れの強いものになっています。

更に、正式版リリースまでの道のりの中で約一年間のプロト・α版・β版というリリースがあり、その過程で様々な技術的チャレンジを行ってきたという、別の視点での強い思い入れもあるということで、今後何度かに分けてその取組みを紹介できればなぁと思ったりしています。

さて、今回はそんなサービスのWebフロントエンド開発の大きな取り組みとして、タイトルにもありますelm導入について、紹介させていただければと。

f:id:fringeneer:20170725230600p:plain

チームの発展をめざして

導入を決定したのは2016年の9月の事、当時は別のサービスの開発を(React, Flux, TypeScript, immutable.js)といった構成でやっておりまして。Uniposについてはα版の開発が始まるか否かというタイミングでワタクシの参画も決まっていたので、β版あたりで新しい取り組みへのチャレンジができないかなーなどと考えていました。

上記構成でのWebアプリケーション開発でも一定の成果は出ており、開発チーム内での知見の共有もある程度進んでいたため、そのまま踏襲することも可能ではあったんですが、より生産性を高め、技術者のレベルを高めるためのチャレンジをして、チームとしての大きなジャンプアップを果たしたいという思いが強くありまして。

「どう作るか」に関しては自分で責任を負うことにして、デメリットがあったとしても、それを覆すことのできるメリットが出せそうであればチームの皆に強力を仰いでブッ込んでしまおう、といった観点でビッグなメリット探しをポイントに、
現状構成から見て、ざっくり①言語の発展、②アーキテクチャの発展という２面での考察を始めました。

elmの美点

当時導入していたTypeScriptについては、JSと比較すると、コンパイラによって、誤りの早期発見や、エディタ上でのコード補完が強力になる、といった恩恵を享受出来ていました。

一方で、型の設定が上手く行っていないと、エラーを検出できなかったり、言語仕様の早いアップデートのキャッチアップ等、メンテナンスのためのコストもそこそこに支払うという課題感を感じたりしていました。

elmを魅力的に感じた点は

純粋関数型言語であり、常に式が値を返し、不変であり、参照透過性を確保出来る点
コンパクトな言語設計により、学習コストは記憶よりも思考に多くを払うことになる
elmアーキテクチャという優れた枠組みが実装されていることにより、アプリケーション基盤の構築コスト(ライブラリの組合せ・依存解決・バージョン管理)がグッと下がる。

などがあります。

なにより、いかにもアカデミックな方向性に向かいそうな出自の言語でありながら、目指している方向はもっとカジュアルなところで、楽しく学ぶことができ、子どもへのプログラミング教育にも使ってもらえるような言語にしていくという言語創設者のEvan氏のメッセージもとても刺さりました。

色々な言語やフレームワークの利用を模索しましたが、将来的に大きな広がりを見せる可能性と、言語自体の面白さ、選民思想ではなく大きな広がりに向かっていく方向性、どれもがビビッと来て、チームを強くし・共に成長していける技術はコレが最高だ！と感じました。

個人的にelmの今後に期待！なポイント

クリティカルな問題というのは正直ありませんでしたね。

主に表現力の部分が高まると良いなーと思う部分はありますが。下記のような事ができると個人的にはうれしいですね。

型を抽象化したり、モジュールに関数の定義を義務化させるような制約をかける、といった機能の実装(いわゆるHaskellの型クラスというやつですね。話し合われてはいるようですが)
Range型のような、Int型ではあるのだけれども1〜10までしか受け付けないという型

導入意思決定から現在

始まってから５年(当時は４年)という若い言語であるという点や、プロダクト導入に踏み切っている企業は殆ど無いと思われる点が懸念ではありましたが、僕はそれを逆に面白いと思っていました。

幸いなことに、技術選定段階や、チームへの紹介での評判も良く、大きな問題があれば引き返すという意思決定も自分が担うことにして、導入を決定しました。

慎重に入れながら、少しずつ前進しては反省を繰り返し、アーキテクチャの細部や開発ポリシーをつめていき、現在ではUniposプロジェクトにおけるelmの稼働コード記述量は3万行近くになっています。

社内にelmを書くメンバーも５人ほどおり、みんなも沢山の新しい発見を得ることができ、徐々に生産性の高い開発技術として社内でも大きな存在感を見せるような認知になってきております。

ちなみに、メンバーへの教育コストはそれほどかけておりません。この手のシンタックスに慣れていない人には、これこれこうでね、とメカニズムを教えてあげればよく、コードレビューも「イベントを表す『メッセージ』」と「状態を表す『モデル』」のレビューに矛盾や重複が無いことをチェックすれば拡張機能開発くらいであれば、根っこが腐るような事はほぼありません。