初めに
こんにちは、株式会社LITALICOにて19卒エンジニアの@M108Kineticsです。
同社でインターンだった頃に、ほぼ独断と偏見でプロダクションコードをTypeScript化した話をご紹介します。
細かい導入お作法ではなく、チームへのインパクトなど比較的エモめな内容になっております。
TL;DR
TypeScriptは不可欠ではないが楽しいしためになる。
対象
世の中には「全人類TypeScript化するべき」みたいなマウント風潮がなくもない気がしますが、過激派はそっとしておきましょう。
実際のところメリデメってどんな感じだったのか、弊チームでの体験をお伝えします。
TypeScriptが最高であることにノーダウトな方にはあまり参考にならないかもしれませんが、
- ちょっと気になってるけど触れられてない
- 既存のプロジェクトに導入してみたいが実際どれぐらいコストがかかるのかよくわからない
- やたらと最近聞くけど本当に必要？
等々感じている皆様に参考になれば幸いです。
チーム
この記事での「チーム」は、リードとなる1~2名の先輩エンジニアの他、4~5名の18卒・19卒の新卒エンジニアで構成されています。
若い衆はいわゆる「文系エンジニア」で、経験も浅いですが日々頑張ってプロダクト開発しています。
動機
導入背景はいたってシンプル、純粋に興味でした。
学生はやたらと新しい技術に触りたがって「〇〇やったことあります」と言いたがってるぐらいがいいんです。（のはず）
フロントエンドに長けた先輩ともちょこちょこ「楽しそうだよね」と話していて、それをゴーサインと勝手に認識してとりあえずイシューだけ立てたのがファーストステップでした。
ふざけたイシューですが、個人的に新しい技術・ライブラリの導入意欲発信のハードルはできるだけ低くていいと考えています。
移行作業
もともとWebpackとBabelを使ってES6を書いていました。
それをJS・TSどちらもをトランスパイルできるようにしたので、移行作業は時間を見つけながらゆっくり行いました。
プルリク数約30、ファイル数でいうと200以上（たぶん）。
今考えるとよく一人でやるなとも思いますが、インターンだからこそできたのかもしれません。
実際終わったのは正社員になってから、一番はじめのプルリクを出してから約半年後でした。
おこがましいことに説明らしい説明も勉強会らしい勉強会もせず勝手に導入し、今となっては6名いる開発チーム全体がTypeScriptを日常的に書いています。
やってよかったと思える理由
仕様・内装を知ろうとする癖がつく
僕はTypeScriptを使うメリットはコードの安全性より何より、「今まで理解しづらかったコードへの窓口を用意してくれる」ことにあると思っています。
完成されているコードって難しい
あるライブラリを利用する場合、ドキュメントをさらっと読んで言われた通りのものを渡せばそれっぽい返り値が返ってきます。
ある別の開発メンバーが用意したモジュールなどを使うときは、直接聞けばなんとなくやるべきことはわかります。
しかしそれだけの理解だとバグ発生の際やモンキーパッチを当てたい時に頭を抱えることになります。
一方で、中身を覗きに行こうとして「どこから始めればいいんだ...」と途方に暮れたことのある方も多いのではないかと思います。
糸口としての「型」
全てのコードを「インプットを受け取って何かしらの処理をし、その結果をアウトプットとして返す」関数として捉えるとします。
インプットである引数とアウトプットである返り値が「どういった形式でどんな情報であるべきなのか」がハッキリとコードの中で定義されているだけで、理解へのとっつきやすさはものすごく変わります。
渡しているどのデータがどのように処理・利用され、最終的なアウトプットとどう関係するのか。これを追うスタートに立てるので、気がついたら大まかな流れを理解できていたりします。
実際の規模感はわからない、巨大に思えるひとつのブラックボックスが、より小さな、案外大したことのないブラックボックスに細分化されていく感じでしょうか。
潜在バグを発見することができた・しやすくなった
JSからTSへの移行は基本的に寝ながらでもできるような作業が大半でした。
が、中には「ほんとにこれで今まで動いてたの！？」と思わせるような型エラーもありました。
そのままだったらまず気付いていなかったでしょうし、何か変更の副作用でバグとして顕在化したとしても原因特定までかなりの時間を要したと思います。
また、導入後のチェック・レビューもしやすくなりました。コードレビューも初心者にとっては基準がよくわからないことが多いかと思いますが、先ほどと同じように「とりあえず引数と返り値の型がちゃんとしているか見よう」と思って始めると、案外指摘点が見つかったりするものです。
デメリット
入れたことによって起きた・起きているダウンサイドはデメリットは、正直特にありません。
なんらかの理由でTypeScriptがオワコンになってJavaScriptに戻すときのコストぐらいでしょうか。
（チームメンバーに文句を言われたら追記します。）
反省
ちゃんとした導入背景・技術説明をチームにしなかった
「なぜ何の為に導入するのか」「導入するなら手順でやるのか」「TypeScriptってなんなのか」といったような説明を、チームに一切せずに進めてしまいました。
TypeScriptは必要になるものではなく、あくまであったらいいものでしかありません。
導入することによっての移行コストや学習コストは払わなければなりません。
そしてさらには、「どこまで徹底するのか」も自由に決めることができるので、チームでのポリシーを決める必要があります。（だからこその過激派）
結果的にペアプロやレビューを通してチーム全体の方針が固まっていきましたが、
きちっと方針を決めてアウトプットするべきでした。
課題
弊チームでのTypeScript運用は@uhyoさんがおっしゃっている「敗北者のTypeScript」です。
anyは移行時にバラまいたものがまだまだありますし、そのほかの「ループホール」を自主規制するポリシーを決め切れてもいません。
ただそれでも導入するだけの価値はあったと個人的には思っています。
これらの課題はこれから、時間をかけて練っていこうと思います。
まとめ
TypeScript導入にはプログラムの理解への手順の取り方を教わりました。
これからはそもそもそれの存在意義、コードの安全性・保守性を意識しながら開発できるように精進したいと思います。
そして新米ながらにも新技術導入を経験させてくれたチームに感謝します。
成果報告のようになってしまいましたが、ここまで読んでいただきありがとうございました。
次回は@YudaiTsukamotoさんの「parcelの時代が中々はじまらないので使いみちを見出してみた」です！お楽しみに！