こう
- 「TypeScript を
使うと 何が 良いのですか」 - 「TypeScript の
弱点や、 気を つけている 所は ありますか」 - 「型を
付けていたのに、 本番で 型と 違う データが 来て 落ちた ことは ありますか」 (仕組みの 理解を、 裏から聞く形)
面接官が
- 「バグが減る」だけで
終わらず、 いつ (書いている とき)、 何が (型の 食い 違い ) 見つかるのかを話せるか - 型は JavaScript に
直すときに 消える、 だから API の 応答や フォームの 入力は 別に 確かめる、 と分かっているか anyで逃げる ことの 危うさと、 手間との 釣り合いを話せるか
短い答え
- TypeScript は JavaScript に
型を 足した 言語で、 動かす前、 書いている 時点で 「数を 渡すはずの 所に 文字列を 渡した」のような 間違いに 気づけます。 - 型が
説明書の 役目もするので、 エディターの 補完や 名前の 付け替えが 正確に なり、 人数が 増えても 安心して 直せます。 - 弱点は、
型は JavaScript に 直すときに 全部消えるので、 API の 応答のように 外から 来た データが 型どおりかは 保証されない ことです。 そこは 別に 検査を 書きます。
少し
書いている
次の
TypeScript
type Item = { name: string; price: number };
function total(items: Item[]): number {
return items.reduce((sum, item) => sum + item.price, 0);
}
total([{ name: "ペン", price: "120" }]);
// 型の検査で、price に文字列を渡した所がエラーになるJavaScript のままだと、"0120" のような
全部にconst count = 3 のように、
型は
TypeScript の
だから、as User と
TypeScript
import { z } from "zod";
const User = z.object({ id: z.number(), name: z.string() });
const res = await fetch("/api/me");
const user = User.parse(await res.json());
// 形が違えば、ここでエラーとして止まる外から
弱点と、
- 手間が増える
型を 書く、 型の エラーを 直す、 JavaScript に 直す手順を 用意する、 などの 手間が かかります - any で穴が開く
型が 分からない 所を anyにすると、 そこから 先は 検査が 効きません。 分からない物は unknownで受けて、 確かめてから使います - 型が
複雑に なりすぎる 凝った 型は 読む人を 困らせます。 読める 型に とどめます
数十行の
自分が
よく
- 「TypeScript なら
実行の ときも 型が 守られる」と思う 型は 消えるので、 外から 来た データは 別に 検査します - 困ったら
anyやasで黙らせる エラーは消えても、 間違いは 残ったままです。 unknownで受けて 確かめる ほうが安全です - 良い
点だけを話す 手間や、 合わない 場面も 言えると、 道具として 選べる 人だと 伝わります
深掘りの問い
- 「any と unknown は
何が 違いますか」 any は 何でも 通して 検査を 止め、 unknown は 確かめるまで 使わせない、と答えます - 「API の
応答に 型を 付ける とき、 どうしていますか」 型を 書くだけでなく、 検査の 道具で 形を 確かめてから 使う、と答えます - 「JavaScript の
プロジェクトを TypeScript に 移すなら、 どう 進めますか」 一度に 全部ではなく、 データの 形や 共通の 関数から 少しずつ移し、 最初は ゆる い設定から 厳しくしていく、と答えます