مشكلة مفاتيح API التي لا تنتهي صلاحيتها أبدًا
المفتاح الذي صدر قبل سنوات، ولم يُبدَّل قط، ولا يزال صالحًا حتى اليوم ليس ميزة مريحة. إنه عبء لم ينظر فيه أحد فعلًا منذ سنوات.
لماذا تكون أخطاء المناطق الزمنية عادة مشكلة اختبار لا مشكلة بيانات
خطأ المنطقة الزمنية لا يظهر تقريبًا أبدًا في يوم ثلاثاء عادي. بل يظهر في الأسبوع المحدد الذي يحدث فيه انتقال التوقيت الصيفي، أو في منطقة غيّرت حكومتها للتو قواعد الفارق الزمني بإشعار قصير، أو عند الحد الفاصل تمامًا بين منطقتين حيث تختار حالة حدية في ربط الإحداثيات بالمنطقة الجانب الخطأ. وفي بقية العام، تعمل الشيفرة التي تتعامل مع المناطق الزمنية بشكل سيئ دون أي مشكلة ظاهرة على الإطلاق، وهذا بالضبط ما يجعل هذه الأخطاء مستعصية: فنمط الإخفاق نادر بطبيعته، لذا نادرًا ما يُكتشف قبل أن يحدث فعلًا في بيئة الإنتاج.
نرى أن معظم هذه الأخطاء تُلقى على البيانات بينما هي في الحقيقة فجوة في الاختبار. فقاعدة بيانات المناطق الزمنية IANA، التي تقوم عليها معظم معالجات المناطق الزمنية الجادة بما فيها معالجتنا، تتتبع هذه الانتقالات وتغييرات القواعد عند حدوثها. لكن توفر البيانات ليس هو نفسه أن يمرّن التطبيق بشكل صحيح مسارات الشيفرة التي لا تعمل إلا خلال أسبوع الانتقال أو لا تنطبق إلا على حفنة من المناطق ذات القواعد غير المعتادة. فإن لم تحاكِ مجموعة الاختبارات أبدًا حد التوقيت الصيفي، أو لم تُجرِ أبدًا استعلامًا على منطقة ذات فارق غير قياسي بنصف ساعة أو 45 دقيقة، فإن صحة البيانات الأساسية لن تنقذ التطبيق من خطأ لا يستطيع منعه إلا مسار الشيفرة غير المختبر الخاص به.
هذه حالة يكون فيها الإصلاح مملًا ومحددًا لا مثيرًا: اختبر صراحةً على التواريخ التي تحدث فيها الانتقالات، لا على تاريخ عشوائي اختير لأنه كان مريحًا فحسب. واختبر عمدًا على حفنة من مناطق الحالات الحدية ذات الفوارق غير المعتادة، لا على المناطق الزمنية الشائعة ذات الأرقام الصحيحة التي يصادف أن معظم التطوير يجري فيها فقط. لا شيء من هذا يتطلب بيانات جديدة. بل يتطلب أن تقرر أن الأسبوع النادر يستحق الاختبار بالعناية نفسها التي يُختبر بها الأسبوع العادي، لأن الأسبوع النادر هو بالضبط حين سيظهر الخطأ لمستخدم حقيقي.
وهناك فخ مرتبط يستحق التسمية: تخزين الفارق الزمني لموقع ما مؤقتًا مرة واحدة وإعادة استخدام تلك القيمة المخزنة إلى أجل غير مسمى. فالفارق الذي كان صحيحًا في يوليو قد يصبح خاطئًا في ديسمبر بمجرد أن يغيّره التوقيت الصيفي، والذاكرة المؤقتة التي لا تأخذ ذلك في الحسبان ستقدّم بثقة إجابة قديمة دون أي إشارة إلى أن شيئًا ما قد ساء. وهذه ليست مشكلة جودة بيانات أيضًا. إنها قرار معماري افترض أن حقيقة ما ستبقى ثابتة بينما طبيعة البيانات كلها أنها لا تبقى كذلك دوريًا.
نصف نقطة النهاية الخاصة بالمنطقة الزمنية لدينا بأنها أحد أجزاء المنتج التي تعمل بالكامل، لأن البيانات المرجعية الأساسية تُصان بنشاط ومنطق الاستعلام مبني ليأخذ هذه الانتقالات في الحسبان مباشرة بدل افتراض فارق ثابت. والنقطة الأكبر تنطبق على ما هو أبعد من منتجنا: فوصول خطأ في المنطقة الزمنية إلى العميل نادرًا ما يكون دليلًا على أن بيانات المصدر كانت خاطئة. بل هو في أغلب الأحيان دليل على أن أحدًا لم يكتب اختبارًا للأسبوع الواحد في السنة، أو للمنطقة الواحدة، حيث تتغير القواعد فعلًا.