外部サービスから記事を取る処理を自分で書いたら、型チェックが通ったのはチェックが効いていなかったからでした

転職用のポートフォリオとして、個人でWebアプリ「Hubpin」を作っています。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
設計と判断は自分で行い、実装も原則自分で書いています。AIには手順書・レビュー・調査を任せています。

外部サービスから記事の一覧を取ってくる処理を書きました。
この処理は、手順書を参照しながら自分で実装しています。

型チェックは通り、テストも緑でした。
それでも間違っていました。
しかも間違いは「チェックが効いていない」ことのほうでした。

境界で any になると、そこから下流は全部素通りする

外部から受け取ったJSONの戻り値は any です。
そこから作った配列に型を書いても、中身は検査されません。

thumbnail_url と書くべきところを thunnail_url と打っていました。
通りました。

取ってきたデータに型を1箇所付けた瞬間、別の行が弾かれました。
タイポを見つけたのは型注釈そのものではなく、any の連鎖を1箇所で切ったことでした。

? を1文字足したら、エラーが3つ出た

省略可能を表す ? を1つ足しただけで、型チェックが3箇所を指しました。
その3箇所は、実行時に落ちる可能性がある場所そのものでした。

「エラーが増えた」というより、「今まで見えていなかった」が正確です。

同じバグを、実行時と型で2回見た

同じことを2つの言い方で言われています。
配列だと思っていたものが、配列ではありませんでした。

「通った」が情報になるのは、落ちる場合があるときだけ

any が混ざった時点で、型チェックは必ず通る装置になっていました。
必ず通るチェックは、通っても何も教えてくれません。

同じ形は、この工程でAIに書いてもらった検証用のSQLでも出ていました。
対象のデータが0件のあいだ、壊れていても「合格」が返る書き方でした。
言語もツールも違うのに、形は同じでした。

検証を書いたら、それが「偽になる条件」を1つ言えるか確かめる。
言えないなら、その検証はまだ何も確かめていません。

any そのものは悪くありません。
外部との境界には必ず出てきます。
問題は、通ったことを情報として扱った自分のほうでした。
境界に1つ型を置くと、下流が一斉に見え始めます。