TypeScriptの勝利。それが私たちにもたらしたもの。

もはやTypeScriptを使うべきかどうかで議論することはない。新しいフロントエンドのプロジェクトでは、デフォルトでTypeScriptが採用されている。議論は終わった。TypeScriptの勝利だ。

「勝利」したことは、単なる結果に過ぎない。真の価値は、型がワークフローにもたらす恩恵にある。それは単にタイポ（打ち間違い）を防ぐだけではない。

関数のシグネチャはドキュメントとして機能する。そして、それが古くなることはない。コードが変更されれば、コンパイラが即座にビルドエラーを出すからだ。

リマインダーをスケジュールする関数を見てみよう。コメントを一行も読まずとも、その関数が必要とするものと、何を返すのかがわかる。通信チャネルの正確な選択肢も一目でわかる。もし新しいチャネルを追加すれば、コンパイラはコードを更新すべき箇所をすべて教えてくれる。コメントであれば、そのまま放置され、内容が実態と乖離してしまうだろう。

リファクタリングが安全になる。型のないコードでは、フィールド名を変更するのは恐ろしい作業だ。文字列を検索して、あとは祈るしかない。しかしTypeScriptなら、型を変更するだけでいい。コンパイラが、壊れた箇所をすべてリストアップしてくれる。リファクタリングはリスクの高い作業ではなくなり、安全なタスクへと変わる。

型はAIの活用も助けてくれる。

型のないJavaScriptの編集をAIに依頼すると、AIはオブジェクトの形状を推測する。一方、TypeScriptを使っていれば、型が「仕様」となる。AIは何が許可されているかを正確に把握できる。エラーは本番環境でのクラッシュではなく、コンパイルエラーとして現れる。型があることで、生成されたコードが「適合するコード」へと変わるのだ。

かつて、型は開発スピードを落とすとさえ言われていた。しかし、AIを活用するワークフローにおいて、型はスピードを加速させる。型はガードレールとして機能する。一行ずつ手作業でチェックする代わりに、生成されたコードを自信を持って受け入れることができるようになる。

以下のルールに従って、より良い型を書こう：

  • 複数のbooleanの代わりにUnion型を使う。「loading」 | 「error」 | 「ready」のようなステータスは、3つの独立したフラグよりも優れている。
  • ドメイン型に名前をつける。単なるnumberではなくCentsのような型を使うことで、意図を示すことができる。
  • anyを避ける。unknownを使用し、型を絞り込む。anyキーワードは、安全網を破壊してしまう。
  • 型推論を活用する。すべてに型注釈を付ける必要はない。境界部分に注釈を付け、あとは推論に任せよう。

TypeScriptは、コードベースを「明示的な契約」へと変えた。この契約があるからこそ、恐れを知らないリファクタリングと、信頼できるAIによる支援が可能になる。

私たちはバグを防ぐために型を使い始めた。そして、型が他のあらゆることの基盤であるからこそ、使い続けているのだ。

Source: https://dev.to/parsajiravand/typescript-won-heres-what-that-actually-bought-us-53lo

Optional learning community: https://t.me/GyaanSetuAi