有効期限のないAPIキーの問題点
何年も前に発行され、一度もローテーションされず、今も有効なキーは、便利なものではありません。何年も誰も実際に確認していない負債です。
タイムゾーンのバグがたいていデータではなくテストの問題である理由
タイムゾーンのバグが普通の火曜日に現れることはほとんどありません。現れるのは、夏時間の切り替えが起こる特定の週や、政府がほとんど予告なくオフセットのルールを変更したばかりの地域や、座標からタイムゾーンへの対応づけのエッジケースが誤った側を選んでしまう2つのタイムゾーンのちょうど境界です。それ以外の時期には、タイムゾーンの扱いがまずいコードでも目に見える問題はまったくなく動きます。まさにそれが、こうしたバグをしぶといものにしています。失敗のパターンがもともとまれなので、本番環境で実際に起こるまでめったに見つからないのです。
こうしたバグのほとんどは、実際にはテストの抜けであるにもかかわらず、データのせいにされていると考えています。私たちのものを含め、本格的なタイムゾーン処理のほとんどの基盤となっているIANAタイムゾーンデータベースは、こうした切り替えやルールの変更を発生時に追跡しています。データが利用できることと、切り替えの週にしか実行されないコードパスや、変わったルールを持つ一握りの地域にしか適用されないコードパスを、アプリケーションが正しく動かしていることとは同じではありません。テストスイートが夏時間の境界を一度もシミュレートしなかったり、標準的でない30分や45分のオフセットを持つ地域に対して一度も検索を実行しなかったりすれば、基礎となるデータが正しくても、アプリケーション自身のテストされていないコードパスでしか防げないバグからアプリケーションを救うことはできません。
これは、解決策が刺激的なものではなく、地味で具体的なケースです。都合がよかったから選んだ任意の日付だけでなく、切り替えが起こる暦上の日付に対して明示的にテストすること。開発のほとんどがたまたま行われている一般的な切りのよいタイムゾーンだけでなく、変わったオフセットを持ついくつかのエッジケースの地域に対しても意図的にテストすること。どれも新しいデータを必要としません。必要なのは、まれな週も一般的な週と同じくらい慎重にテストする価値があると判断することです。まれな週こそ、実際のユーザーに対してバグが表面化する時だからです。
関連して、指摘しておくべき落とし穴があります。ある場所のタイムゾーンのオフセットを一度キャッシュし、そのキャッシュした値を無期限に使い回すことです。7月に正しかったオフセットも、夏時間でずれれば12月には間違っていることがあり、それを考慮しないキャッシュは、何か問題が起きたことを示すことなく、古い答えを自信たっぷりに返し続けます。これもデータ品質の問題ではありません。データの本質がまさに定期的に一定でなくなることにあるのに、ある事実が一定のままだと想定したアーキテクチャ上の判断です。
私たちはタイムゾーンのエンドポイントを、製品の中で完全に機能している部分の1つとして説明しています。基礎となるリファレンスデータは積極的に保守されており、検索のロジックは静的なオフセットを前提とするのではなく、こうした切り替えを直接考慮するように作られているからです。より大きなポイントは私たち自身の製品を超えて当てはまります。タイムゾーンのバグがお客様のもとに届くことは、元のデータが間違っていた証拠であることはめったにありません。はるかに多くの場合、それはルールが実際に変わる年に1週間、あるいは1つの地域について、誰もテストを書かなかった証拠なのです。