कभी एक्सपायर न होने वाली API कुंजियों की समस्या
कई साल पहले जारी की गई कुंजी, जिसे कभी रोटेट नहीं किया गया और जो आज भी मान्य है, कोई सुविधा नहीं है। यह एक जोखिम है जिसे सालों से किसी ने वास्तव में देखा तक नहीं।
समय क्षेत्र के बग आमतौर पर टेस्टिंग की समस्या क्यों होते हैं, डेटा की नहीं
समय क्षेत्र का बग लगभग कभी किसी सामान्य मंगलवार को सामने नहीं आता। यह उसी ख़ास हफ़्ते में सामने आता है जब डेलाइट सेविंग का बदलाव होता है, या किसी ऐसे क्षेत्र में जिसकी सरकार ने बिना ज़्यादा पूर्व सूचना के अपने ऑफ़सेट नियम बदल दिए, या दो क्षेत्रों की ठीक उस सीमा पर जहाँ निर्देशांक-से-क्षेत्र मैपिंग का कोई एज केस ग़लत पक्ष चुन लेता है। साल के बाक़ी समय, समय क्षेत्रों को ख़राब ढंग से संभालने वाला कोड बिना किसी दिखाई देने वाली समस्या के चलता है, और यही बात इन बगों को इतना टिकाऊ बनाती है: विफलता की स्थिति अपने स्वभाव से दुर्लभ है, इसलिए यह तब तक शायद ही पकड़ी जाती है जब तक प्रोडक्शन में वास्तव में हो न जाए।
हमें लगता है कि इनमें से ज़्यादातर बगों का दोष डेटा पर डाला जाता है, जबकि असल में ये टेस्टिंग की कमी होते हैं। IANA समय क्षेत्र डेटाबेस, जो हमारे सहित ज़्यादातर गंभीर समय क्षेत्र हैंडलिंग का आधार है, इन बदलावों और नियम परिवर्तनों को होते ही ट्रैक करता है। डेटा का उपलब्ध होना इस बात के बराबर नहीं है कि कोई ऐप्लिकेशन उन कोड पाथ को सही ढंग से चलाता है जो केवल बदलाव वाले हफ़्ते में चलते हैं या केवल असामान्य नियमों वाले गिने-चुने क्षेत्रों पर लागू होते हैं। अगर कोई टेस्ट सूट कभी डेलाइट सेविंग की सीमा का सिमुलेशन नहीं करता, या कभी गैर-मानक आधे घंटे या 45 मिनट के ऑफ़सेट वाले क्षेत्र पर लुकअप नहीं चलाता, तो मूल डेटा का सही होना किसी ऐप्लिकेशन को ऐसे बग से नहीं बचाएगा जिसे केवल उसका अपना बिना टेस्ट किया गया कोड पाथ ही रोक सकता है।
यह ऐसा मामला है जहाँ समाधान रोमांचक नहीं, बल्कि उबाऊ और विशिष्ट है: उन कैलेंडर तारीख़ों पर साफ़ तौर पर टेस्ट करें जब बदलाव होते हैं, न कि केवल किसी मनमानी तारीख़ पर जो सुविधाजनक होने की वजह से चुनी गई। जानबूझकर असामान्य ऑफ़सेट वाले कुछ एज केस क्षेत्रों पर टेस्ट करें, न कि केवल उन आम, गोल संख्या वाले समय क्षेत्रों पर जिनमें ज़्यादातर डेवलपमेंट संयोग से होता है। इनमें से किसी के लिए नया डेटा नहीं चाहिए। इसके लिए यह तय करना ज़रूरी है कि दुर्लभ हफ़्ता उतनी ही सावधानी से टेस्ट करने लायक़ है जितना आम हफ़्ता, क्योंकि दुर्लभ हफ़्ता ठीक वही समय है जब बग किसी असली उपयोगकर्ता के सामने आएगा।
एक संबंधित जाल का ज़िक्र करना ज़रूरी है: किसी लोकेशन का समय क्षेत्र ऑफ़सेट एक बार कैश करना और उस कैश किए गए मान को अनिश्चित काल तक दोबारा इस्तेमाल करना। जुलाई में सही ऑफ़सेट दिसंबर में डेलाइट सेविंग से बदल जाने के बाद ग़लत हो सकता है, और जो कैश इसका ध्यान नहीं रखता वह बिना किसी संकेत के पूरे भरोसे से पुराना जवाब देगा कि कुछ ग़लत हुआ है। यह भी डेटा गुणवत्ता की समस्या नहीं है। यह एक आर्किटेक्चर फ़ैसला है जिसने मान लिया कि कोई तथ्य स्थिर रहेगा, जबकि उस डेटा का पूरा स्वभाव ही यह है कि वह समय-समय पर स्थिर नहीं रहता।
हम अपने समय क्षेत्र एंडपॉइंट को प्रोडक्ट के उन हिस्सों में गिनते हैं जो पूरी तरह काम कर रहे हैं, क्योंकि मूल संदर्भ डेटा का सक्रिय रूप से रखरखाव होता है और लुकअप लॉजिक किसी स्थिर ऑफ़सेट को मानने के बजाय इन बदलावों को सीधे ध्यान में रखने के लिए बनाया गया है। बड़ी बात हमारे अपने प्रोडक्ट से आगे लागू होती है: किसी ग्राहक तक पहुँचा समय क्षेत्र का बग शायद ही कभी इस बात का सबूत होता है कि स्रोत डेटा ग़लत था। यह कहीं ज़्यादा अक्सर इस बात का सबूत होता है कि किसी ने साल के उस एक हफ़्ते, या उस एक क्षेत्र, के लिए टेस्ट नहीं लिखा जहाँ नियम वास्तव में बदलते हैं।