これは TypeScript Advent Calendar 2019 25日目の記事です。みなさん、メリークリスマス。今年も無事サンタ業を終え、YouTube Musicを垂れ流しながらクリスマスだしTypeScript関連のポエムでも書こうかなとしているとこです。

Background

私の所属する会社の某ホスティング事業部では、今年のはじめあたりにフロントエンドとBFFの技術指針として開発言語のベースをTypeScriptにしましょうというのを決めました。そのような決め事をしたのは、まず、開発に様々な言語が使用されているという経緯からでした。現場レベルで、開発に使用したい言語を柔軟に選択できることはモチベーションの１つとしては良いのですが、中長期的な運用をしなければならないこと、１つのチームが複数のプロジェクトの面倒みなければならないこと（これはこれで問題なのですが）を踏まえると、やはり開発のモチベーションより運用のコストを下げるべきであるという選択をしたわけです。もちろん、未来永劫TypeScript以外で開発ができないのかというとそうではなく、現状特段の理由がない限りTypeScriptで開発をしましょうというものです（ちなみに、技術指針には使用言語以外のことも定義しています）。

Why TypeScript

次に、なぜTypeScriptにしたのかを書いていきます。私たちが運営するサービスは提供はじめてもう20年近くになり、如何にレガシーコードと向き合うかが長年の課題です。そして、多くのプロジェクトが本番で稼働しているために、言語やフレームワークはもちろん依存ライブラリのアップデートを継続的にやらなければなりません。全体最適化を考えると、やはり指針のようなものが必要であると考えた私は、各プロジェクトの言語と行数を集計してみました。7割がPHPで1割がJavaScript、あとの2割をPerlやGoそしてRubyで分け合うという結果でした。思っていたよりPHPの占める割合が多く、これでPHPのバージョンが新しめだったらPHPで行きましょうとなっていたと思います。先に申し上げた通り、私たちはレガシーコードと共にいます。つまり、リプレースが必要な資産でもあるため、リプレースを見越すのであれば、型安全や型推論による開発／運用効率に分がある静的型付け言語を推していきたいと考えたわけです。こうなってくると、フロントエンドとBFFの指針を策定するのに、ブラウザ上の唯一のランタイムであるJavaScript（現状WAは直接動作しないので除く）は逃れられない要素です。なのでいっそ全てJavaScriptにしてFrontendとBackendの資産を共有できること、１つの言語に絞ることで採用に有利に働くこと、エンジニアの配置をフレキシブルにできること、をメリットとして、TypeScriptを開発言語のベースにしました。

Afterwords

もともと、複数のチームでTypeScriptの開発と運用実績がありましたので、これらの提案に対してネガティブなものはありませんでした。今後もTypeScript以外の運用はしなければなりませんが、ソフトウェアエンジニアである以上、どんな言語でも対応できるのがプロフェッショナルの仕事だと思う一方で、大変さはわかるので社内で支援できる環境づくりは別に進めている状態ではあります。

このように、仕事のメンバーで技術指針を共有することでメンバー個人が何を習得しなければならないかが自明になり、メンバー間で知見の共有が増えているように思います。また、会社だけでなく、TypeScriptの技術コミュニティを（福岡で）つくってTypeScriptで開発をする仲間を（所属会社関係なく）増やしていく活動しています。いい話でしょ？ではみなさま、良い新年をお迎えください。メリクリ。