January 10, 2019

TypeScript に期待しすぎる前に胸に手を当てて考えること

テストコードを書いたからと言って即プロダクトの品質が上がるわけないのと同様に、 JavaScript で書かれたコードベースを TypeScript に移行しただけで即品質が上がるかというとまぁそうじゃないので、それ以前のところからシュクシュクとやっていこうね…という気持ちです。
— 北宇治高校の壁のシミ (@cheezenaan) 2019年1月9日

自動テストも静的型付けによるチェックも、ｶﾞ−ｯと書いたコードのフィードバックを手っ取り早く得るための効率的な手段という側面では共通していると思ってて、それが実際にプロダクトコードの設計改善につながっていくと、ちょっとだけだけど気分がよくなってしまうアレです
— 北宇治高校の壁のシミ (@cheezenaan) 2019年1月9日

意識高い系なことをﾂｲｰﾖした勢いで、最近思うことを深夜のノリで書きなぐってみる。

おことわり

TypeScript の仕様に関する話とか、JavaScript から TypeScript への移行話とか、具体的なサンプルコードは一切出てきません

Tl;dr

TypeScript をはじめとした静的型付け言語は自動テストと同じで「導入すれば即プロダクトの品質が上がる」というものではない
「プロダクトの品質を上げる = プロダクトコードの設計を改善する」ことは型のあるなし関係なく、世に出回っている原理原則に基づいて行える
オブジェクトの構造や振る舞いに型をつけていく過程で、よりよい設計にしていくためのリトマス紙として活用する…くらいのスタンスで TypeScript に接していきたい

たとえばこういう話

※この物語はフィクションです

とある JavaScript プロジェクトの *.js ファイルの拡張子を *.ts に変えて型をつけはじめていくと、なんだか型をつけづらいオブジェクトが発生した
コードベースを追っていくと、とある処理をする際に複数オブジェクト間で互いのことを参照していたりで、依存関係が必要以上に絡みあっていた
- イメージとしてはこの図みたいなやつ
単体テストのコードも存在していたが、テストを回すためのダミーオブジェクトがちょくちょく出てきて、怪しそうな雰囲気が出ていた
オブジェクト間の依存関係がなるべく単方向になるように、それぞれの責務を意識しながら分割しなおして、テストコードも都度修正した
型をつけづらかったオブジェクトもスッキリしてテストしやすくなったし、最終的により具体的で洗練された型をつけられるようになった

参考