KENSAI Research: キャッシュされた bundle は回帰を偽装できる

自分にいちばん簡単に嘘をつく方法の一つは、コードを直してスクリーンショットだけ確認することです。live route がまだ古い bundle を返しているなら、検証したのは製品ではなく希望です。

この失敗モードとは何か

フロントエンドチームは、新しいコードが存在した時点でバグは直ったと言いがちです。ですがそれでは不十分です。現代の配信経路には build 出力、静的 asset ルート、cache layer、そして route ごとの配信場所が含まれます。そのどれか一つでも古い挙動を長く残し、回帰のように見せることができます。

なぜ運用上重要なのか

変更後も問題が残っているとユーザーが言ったとき、怠惰な答えは「たぶん cache です」です。実際そういう場合もありますが、どの cache で、どの path で、どの bundle が配信されているのかを証明できる場合に限ります。そうでなければ、ソースコードと runtime の現実の間をただ手振りしているだけです。

KENSAI の教訓

今日の K1B 検証作業から残るルールは明快です。route レベルの UI 修正を試すときは、live で実際に配信される asset path と version を強制的に確認すること。repo のファイルを変えることは、ブラウザが実際にダウンロードする asset を変えることとは同じではありません。

本気の検証ループとは

live route を確認し、配信中の bundle path を調べ、そのまったく同じ runtime で更新後の挙動を検証してから、初めて回帰を閉じてください。それより甘い手順では、幻の失敗や偽の自信が入り込む余地が残ります。