Zenn
🥂

書かない勇気、書くやさしさ。

に公開
JavaScript
tech

はじめに

JavaScript をそれなりに書いてきたあなたなら、
「型なんてなくても動くし」と思ってしまう瞬間、ありませんか？

TypeScript を触り始めると、やたら目にする : string や : number。
ふと、「これ、全部書く必要あるの？」という問いが浮かびます。

結論から言うと、推論できるところには、書かなくて大丈夫。

でも、オブジェクトの構造は、少し話が違います。
そんなときこそ、インターフェースの出番。

この記事では、JavaScript の延長線で理解できる範囲のまま、
「どこに型注釈を置くか」
「インターフェースって、どう役立つのか」
そんなことを、やさしく見つめていきます。

1. 推論が効くなら、お任せしよう

TypeScript は、とても賢い。
注釈を書かなくても、「これは文字列」「これは数値」と察してくれます。

const name = "Yamada";
let count = 0;
const isAdmin = true;

このコード、どれも型注釈はナシ。
けれど name は string、count は number、isAdmin は boolean。
ちゃんと、わかってくれています。

だからこそ、「見たらわかるもの」には書かなくていい。
型注釈は、ただの機械のためじゃなく、
読み手に手がかりを渡すためのもの。

書くなら、「読んだ人が、少しほっとできるところ」に。

2. データの「構造」を示すインターフィス

型注釈の真価は、「かたちのあるデータ」に宿ります。
つまり、オブジェクト。

interface User {
  id: number;
  name: string;
  email?: string;
}

function sendWelcome(user: User) {
  console.log(`Welcome, ${user.name}!`);
}

この User インターフェースがあるだけで、
「この関数は、こんなデータを求めているんだな」
それが、一目でわかります。

これはもう、型というより、小さな設計図。

ちなみに email? の ? は、
「あるかもしれないし、ないかもしれない」という、やわらかな余白。
TypeScript は、そんなあいまいさにも、きちんと寄り添ってくれます。

3. インターフェースの拡張で、使いまわせる設計に

TypeScript のインターフェースは、そっと拡張もできる。
構造を「使いまわす」というより、やさしく「重ねる」感じ。

interface Timestamped {
  createdAt: Date;
  updatedAt: Date;
}

interface Post extends Timestamped {
  title: string;
  content: string;
}

これで Post 型には、createdAt と updatedAt が自然に含まれます。

現実のアプリでは、ユーザーにも記事にも「作成日時」があるもの。
同じかたちを切り出して、そっと使いまわせる。
そんな設計は、美しくて、静かに心地いい。

4. 型注釈は「他人のため」に書こう

型をつけるかどうか、迷ったときは、
「これを読んだ他の誰かが、どう感じるか？」を考えてみてください。

とくに、オブジェクトを受け取る関数には、
その構造がわかるように、やさしく添えておくと親切です。

でも、変数の型が明らかなら、無理に注釈を加えなくてもいい。
TypeScript の型推論はとても賢いから、
まかせられるところは、まかせてしまう。

それが「書かない勇気」。

まとめ

  • 型注釈は、「必要なところ」にだけ置く
  • オブジェクトの構造は、インターフェースで静かに明示する
  • インターフェースは拡張できて、設計が整う
  • 型は「未来の自分」と「チームメンバー」へのやさしさ

TypeScript の型は、ルールではなく、味方です。

全部書かなくてもいい。
「ここに型があると、読みやすいな」と思える場所にだけ、
そっと添える。

それが、書かない勇気、書くやさしさ。
型との、ちょうどいい距離感かもしれません。

Discussion