typescriptで any を使ってもいいのか?問題の解決策(の一例)
Typescriptを既存プロジェクトに導入するケースが昨今増えていますが、その場合に苦労することの一つとして「Type(型)がわからない&検証が面倒臭い」がよくあります。
「よし!tsいれるぞ!」
「ここはstring... こっちはnumber... お!これはIUserとしておこう...」
「ん?IUserのbirthdayってなんだ...?」
「API仕様書ないし... 面倒だから一旦any
にしておこう 」
そもそもTypescriptでanyは悪なのか?
個人的な考えとしては「ts中途導入であれば必要悪」という感じです。
既存アプリケーションのフロントエンドが膨大であれば、それら一つ一つに型を正確につけていくことはかなりの重労働です。しかも、型をつけたからといってアプリケーション自体が利益を生むわけではないため、分かりやすいビジネス上のメリットはありません。
一方で、anyが横行すればtsの恩恵を受けられません。中途半端に型をつけたアプリケーションほど厄介なものはありません。
そこでFIX_ME_ANYという型
これはTypescript Meetupという勉強会で聞いたテクニック(?)ですが、type FIX_ME_ANY
を定義し、それをanyとして扱うという技がありました。
このメリットは
- 本当にanyな場合と、後でなんとかするのanyを明示的に分けられる
- 割れ窓理論で横行しやすいanyに対して一度再思考を促すことができる
と考えています。
イメージ
type FIX_ME_ANY: any; interface IUser { name: string; age: number; birthday: FIX_ME_ANY; }
こうすることで、一見してそれが本当にanyなのか(まあ基本的にanyが必須な場合はそうそうないが...)、一旦anyにしているだけなのか、ということがコードからわかるようになりました。