بعد تقييد النموذج مفتوح المصدر، أول ما يجب أن يكون مستقلاً هو الطبقة المحايدة للنموذج.

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

عادة ما يكون من الصعب اعتبار هذا النوع من المشاكل مشكلة معمارية. خلال مرحلة التطوير، رأيت فقط “يمكن تشغيله”. بعد الاتصال بالإنترنت، اكتشفت أن اختيار النموذج قد تم كتابته بالفعل في منطق الأعمال. تتكيف بعض الحقول فقط مع تنسيق إرجاع واحد فقط، وبعض عمليات إعادة المحاولة تتعرف فقط على طريقة رفض واحدة، وبعض الاستثناءات الافتراضية هي النموذج الأصلي لتقديم شرح أطول. بمجرد فرض القيود، تم الكشف عن كل هذه الأكوام المخفية.

السلوك الافتراضي سيربط النموذج بالأعمال

في مرحلة الوصول، غالبًا ما يُنظر إلى النموذج على أنه إضافة SDK، وربط واجهة برمجة التطبيقات، وإضافة كلمة مطالبة. بعد الاتصال، فإن أصعب شيء في التنظيف ليس المكالمة نفسها، ولكن الفروع التي نمت حول السلوك الافتراضي. ما إذا كان يجب أن يكون الإخراج JSON بشكل صارم، وما إذا كان يجب محاولة استدعاء الأداة مرة أخرى بعد الفشل، ومكان اقتطاع الإدخال الزائد، والطبقة التي سيتم وضع مطالبات التحكم في المخاطر عليها. غالبًا ما تقع هذه المشكلات في قانون العمل.

بمجرد تقييد نموذج مفتوح المصدر أو إزالته من الرفوف، أو عندما تبدأ الصورة المحلية والنسخة الأولية في التفرع، فإن هذه السلوكيات الافتراضية لم تعد موثوقة. ظاهريًا، يتم مجرد تغيير النموذج، ولكن تحته من الضروري تغيير التحليل والمراقبة والتراجع والاختبار في نفس الوقت. الجزء الأكثر صعوبة هو عدم كتابة بضعة أسطر إضافية من التكيف، ولكن عدم تحديد المجموعة الأصلية من الافتراضات بشكل واضح من البداية إلى النهاية.

دور الطبقة المحايدة هو نشر الافتراضات الضمنية

الطبقات المحايدة للنموذج ليست مجردة من أجل التجريد. وظيفتها بسيطة للغاية: وضع الكلمات السريعة، والتحقق من المخطط، والتوجيه، وإعادة المحاولة، والرجوع إلى إصدار أقدم، والسجلات، والتقييم في مكان واحد، بحيث تمر اختلافات النماذج أولاً عبر نفس مجموعة الحدود. بهذه الطريقة، حتى لو تم استبدال النموذج بالسحابة أو المصدر المفتوح أو الاستدلال المحلي أو موفري الخدمات الآخرين، ستظل الشركة ترى عقدًا موحدًا للمدخلات والمخرجات.

وبمجرد إنشاء هذه الطبقة، فإن العديد من الأشياء التي لم تكن واضحة في الأصل سوف تصبح واضحة فجأة. ما هي الحقول التي تمثل قيمًا مطلوبة، وما هي الحقول التي تعد مجرد تفضيلات نموذجية، وما هي حالات الفشل التي يمكن إعادة محاولتها، وما هي حالات الفشل التي يجب التراجع عنها، وما هي السياقات التي سيتم اقتطاعها، وما هي المؤشرات التي يمكن مقارنتها بالفعل، ستتغير جميعها من “يتم تذكرها بالخبرة” إلى “مقيدة بواسطة الواجهات”. لم يعد يتم إدخال التأثير الناتج عن النموذج المحدود مباشرة في كود العمل، ولكن أولاً في الطبقة المحايدة.

ليست كل المشاهد تستحق هذه الطبقة

لا تحتاج بعض المشاهد إلى أن تكون الطبقات سميكة جدًا على الإطلاق. الملخصات لمرة واحدة، والتوليد المؤقت، والتجارب الداخلية، وسلاسل الأدوات المقفلة ذات النموذج الواحد تمامًا، تكفي لتوصيل النموذج في هذه الأماكن. إن بناء طبقة محايدة كاملة لعملية قصيرة الأجل لن يؤدي إلا إلى تجاوز التكلفة مقدمًا.

هذه الطبقة مطلوبة حيث سيشارك النموذج فعليًا في الحكم على الأعمال. مثل الاستخراج والتوجيه وتنفيذ الأداة واستجابة خدمة العملاء والمساعدة في المراجعة وإعادة كتابة الدُفعات. في هذه السيناريوهات، النموذج ليس لعبة، ولكنه جزء من العملية. وطالما أن النموذج قد يتغير، أو أن القيود الخارجية قد تؤدي إلى زعزعة استقرار مدخل معين، فإن الطبقة المحايدة ليست زخرفة بل جدار يحافظ على التغيير داخل الحدود.

ما يجبر حقًا على تقييد نموذج المصدر المفتوح ليس البديل عن مورد محدد، ولكن ما إذا كان الفريق يعامل “اختلافات النماذج” كمواطنين من الدرجة الأولى. كلما تم نشر السلوك الافتراضي في التعليمات البرمجية في وقت مبكر، كلما كان أقل سلبية عند تغيير النماذج لاحقًا. يمكن للنموذج أن يتغير، لكن الحدود لا يمكن أن تتبعه.