ある設定を変えるのに、いちばん近い道を選びました。データベースへの直接書き込みです。書き込みは成功し、クエリを投げれば新しい値が返ってきます。それなのに、アプリケーションが読んでいるのは古い値のままでした。症状が、間違った場所を指すその設定は、どのテーマを有効にするかを決めるものでした。古い値が読まれた結果、新しいテーマはまったく読み込まれず、スタイルも関数もないまま、フロント全体が初期状態の見た目に戻りました。これは「新しいテーマにエラーがあり、システムが自動でデフォルトに戻した」ときとまったく同じ見え方です。私たちもしばらくその方向で調べました。構文、必須ファイル、テーマ宣言の書式。すべて正常でした。切り分けの基準システムに2つ尋ねます。そのテーマにエラーはあるか。システムはそのテーマを一覧に出せるか。エラーが空で、一覧にも出てくるなら、テーマは壊れていません。問題は両端ではなく、その間にあります。自分とデータベースのあいだに、何かが立っているのです。それが常駐のオブジェクトキャッシュでした。アプリケーションは設定を読むとき、まずキャッシュに問い合わせます。キャッシュに値があれば、データベースまでは見に行きません。2つのルール① アプリケーション層を通さずに書き込んだら、必ずキャッシュをクリアする。② クリアしたら、別のプロセスで確かめる。同じプロセスの中では、スタイルも関数もキャッシュをクリアする前に読み込みが終わっています。その場で確認するとまだ空のままなので、クリアしても意味がなかったと思ってしまう。私たちはここでもつまずきました。もう一段大きな教訓近道をすること自体は悪くありません。悪いのは、近道をしたときに、自分が何を飛ばしたのかを忘れることです。キャッシュは1層ごとにひとつのコピーで、コピーはひとつごとに嘘をつく機会になります。