محول واحد، ولا شيء يتسرب من خلاله
القاعدة بسيطة، لكنها تُخالف باستمرار: هناك وحدة واحدة فقط تعرف شكل النظام القديم، وهي تعرض أنواعك، وليس أنواعها الخاصة.
- داخل المُحول: لغة XML الخاصة به، وتنسيقات التاريخ الخاصة به، ورموز الحالة السحرية الخاصة به، وفترات الانتظار التي تبلغ خمس دقائق، وعادته في إرجاع الرمز 200 مع وجود خطأ في نص الرسالة.
- خارج المحول: كائنات المجال الخاصة بك، والأخطاء العادية، وحالات انتهاء المهلة العادية.
- الاختبار: هل يمكنك حذف النظام القديم وإعادة تنفيذ المُهايئ مع عنصر آخر دون المساس بأي شيء في المراحل السابقة؟ إذا لم يكن الأمر كذلك، فهذا يعني أن هيكله قد تسرب، وسوف يستمر التسرب.
غالبًا ما يكون التسرب عبارة عن تاريخ أو رمز حالة أو قيمة فارغة. وهذه العناصر الثلاثة هي السبب في معظم الحالات التي اكتشفنا فيها وجود خلل قديم يتكرر في منطق الأعمال على بعد أربع وحدات برمجية.
ما الذي يمكن توقعه، حتى تتمكن من التخطيط له
- إنه يكذب بشأن الفشل
- رمز الحالة HTTP 200 مع وجود خطأ في الحمولة، أو نتيجة فارغة حيث تعني "خطأ". قم بتحليل نص الرسالة، ولا تعتمد أبدًا على رمز الحالة وحده.
- لا يحتوي على ترقيم الصفحات
- أو أن ترقيم الصفحات غير ثابت عبر الصفحات مع تغير البيانات. التقط لقطة أولاً، ثم انتقل إلى الصفحة.
- ساعته معطلة
- أو في منطقة زمنية أخرى، أو بالتوقيت المحلي دون أي فارق زمني. قم بتوحيد التوقيت وفقًا لتوقيت UTC عند الحدود ولا تعتمد على التخمين أبدًا.
- يحتوي على حد معدل مخفي
- غير موثق، ويتم تطبيقه عن طريق إبطاء السرعة بدلاً من الرفض. أضف الحد الخاص بك أدنى من القيمة التي قمت بقياسها.
- لا يمكن إجراء اختبار التحميل عليه
- نظرًا لأنها مشتركة مع عملية الإنتاج، فلن يقوم أحد بإيقافها مؤقتًا. افترض أن لديك فرصة واحدة فقط في ذروة النشاط، وصمم النظام بحيث يتكيف مع انخفاض الأداء بشكل سلس.
اجعلها قابلة للاختبار بدونها
لن تحصل على نسخة تجريبية. افترض ذلك منذ البداية، وافترض أن المشروع سيصمد أمام هذا الوضع.
- قم بتسجيل أزواج الطلبات والاستجابات الفعلية من أي وسيلة وصول متاحة لديك، بما في ذلك تلك التي تحتوي على أخطاء في الصيغة. فهذه الأزواج أكثر قيمة من أي مواصفات قد تُزوَّد بها.
- قم بإنشاء نسخة مزيفة من تلك اللقطات تعيد عرضها، بما في ذلك حالات الفشل والبطء.
- قم بتشغيل مجموعة الاختبارات بالكامل على النسخة الوهمية. وهذا ما يتيح لك مواصلة التطوير يوم الثلاثاء، عندما يكون النظام معطلاً بسبب إغلاق الحسابات في نهاية الشهر.
- قم بإجراء اختبار صغير للعقد مقارنةً بالعقد الفعلي وفقًا لجدول زمني محدد، حتى تتمكن من اكتشاف اليوم الذي يتغير فيه سلوكه دون سابق إنذار.
اختبار العقد هو ما يُعلمك بأن المورد قد أجرى تصحيحًا ما. ففي إحدى المهام، كشف الاختبار عن تغيير في تنسيق التاريخ من «اليوم أولاً» إلى «الشهر أولاً»، وهو ما كان سيؤدي لولا ذلك إلى حدوث خطأ خفي في تواريخ ربع الإدخالات.
لا تدع ذلك يحدد وتيرة الأمور
إن أكثر ما يسبب الضرر في أي نظام قديم ليس أمراً تقنياً. فهو يبطئ كل قرار إلى السرعة التي يحددها من يملكه.
- قراءة البيانات عبر المحول، وكتابة البيانات عبر قائمة الانتظار. وعند حدوث تعطل، يؤدي ذلك إلى تأخير العمل بدلاً من إخفاقه.
- تخزين البيانات المرجعية مؤقتًا محليًّا مع تحديد مدة صلاحيتها. فلا داعي لاستدعاء قائمة الحسابات في كل عملية استدعاء.
- لا تجعله أبدًا متزامنًا في مسار يواجه المستخدم. فمعدل الأداء p99 الخاص به سيصبح معدل الأداء الخاص بك.
- دوّن ما طلبته ولم تحصل عليه. وعندما يبدأ مشروع الاستبدال، ستصبح تلك القائمة هي وثيقة المتطلبات.
هل تريد أن ننفّذ هذا معك؟
التدقيق هو هذه المنهجية موجّهة إلى أنظمتك، وفي نهايته خطة بناء مُسعّرة.
تحديد موعد مكالمة