فاحص توافق نسخ مخطط Protobuf: مشاريع تخرج هندسة البرمجيات

يوجد إصداران من خدمة الرسائل في البيئة نفسها؛ الكاتب الجديد يرسل payload بينما القارئ القديم لم يحدث بعد. السؤال ليس هل يترجم ملف proto، بل هل يمكن لكل قارئ تفسير رسائل الكاتب في الاتجاهين من دون إسقاط معنى الحقول؟ نبني checker حول مصفوفة old/new writer مقابل old/new reader. هذه زاوية عملية لمشاريع تخرج هندسة البرمجيات. ارجع إلى دليل Proto3 ودليل field presence؛ فالتوافق يعتمد على التغيير وسياق القراءة.

صنف الأثر بدرجات مفهومة

مثلاً، إضافة حقل جديد غالباً wire-safe في Protobuf binary حسب الدليل، لكن التطبيق قد لا يتعامل جيداً مع قيمته الافتراضية. تغيير رقم حقل موجود خطر، وحذف field يحتاج حجز رقم واسمه. تغيير int32 إلى int64 قد يكون متوافقاً في اتجاهات معينة لكنه قد يفقد قيمة كبيرة لدى قارئ أقدم، ولذلك يجب تصنيفه مشروطاً لا آمناً بلا قيد. أظهر اتجاه القراءة: old writer إلى new reader، ثم new writer إلى old reader. لا تكتب علامة pass واحدة تخفي أن أحد الاتجاهين فقط نجح.

حلل المخطط كعقدة لا كسطر نص

يبدأ النموذج بقراءة message وfield name وfield number وtype وcardinality وoneof وenum، ثم يطابق الحقول بالاسم والرقم. أخرج تغييراً منظماً لكل عنصر: إضافة، حذف، تغيير رقم، تغيير نوع، نقل إلى oneof، أو حذف قيمة enum. احتفظ بتعليقات وملفات import في مصدر منفصل حتى لا يفقد المطور الأصل. يمكن استعمال parser رسمي بدلاً من regex؛ فالنص قد يحتوي تعليقات متداخلة أو خيارات وأقواساً. لكل نتيجة اكتب قاعدة مكتوبة وإصدار المرجع الذي اعتمدته، ووضح هل الحكم ثنائي أم قد يكسر كود التطبيق رغم بقاء الرسالة قابلة للقراءة.

أنشئ أربع خلايا: old writer مع old reader، old writer مع new reader، new writer مع old reader، وnew writer مع new reader. لكل خلية احفظ payload bytes ثم نتيجة فك الرسالة والقيم التي بقيت أو اختفت. لا تختزل backward وforward إلى شارة واحدة؛ حدد أي طرف يرسل وأي طرف يقرأ. أظهر الحقول المحفوظة كـunknown fields إن كانت بيئة التنفيذ تحفظها، واختبر إصدار المكتبة المستخدم بدلاً من افتراض السلوك.

مثال مخطط تدريبي

تخيل Message اسمها StudentTask فيها string title = 1 وbool complete = 2. في نسخة لاحقة حذف الفريق complete وأضاف string state = 2. يرى الفاحص أن الرقم 2 أعيد استخدامه بنوع مختلف، ويقترح حجز الرقم والاسم القديمين ثم إضافة state برقم لم يستخدم سابقاً. يشغل الاختبار payload محفوظاً من النسخة السابقة عبر parser الجديد والعكس، ويحفظ الناتج JSON للمقارنة. المثال توضيحي، وليس تقريراً عن مخطط منشور. لا تعتمد على الاسم فقط؛ إذا تغير الاسم مع بقاء الرقم فقد تستمر قراءة wire لكن تتأثر صيغ JSON وأدوات أخرى.

أرقام الحقول جزء من wire format

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

مصفوفة اختبار للقارئ والكاتب

خط الأساس هو protoc ونسختا المخطط الرسميتان، مع fixtures ثنائية محفوظة لكل إصدار. اختبر إضافة حقل، حذفاً محجوزاً، إعادة رقم قديم، تغيير نوع، enum جديداً، واستيراد ملف لا يمكن تحليله. شغل أربع عمليات: serialize بالقديم وparse بالجديد، والعكس، ثم serialize/parse داخل النسخة نفسها. قارن القيم لا مجرد exit code. يجب أن يوقف الفاحص إخراج حكم إذا كان import ناقصاً أو parsing فشل. سجل أي تغيير يحتاج مراجعة يدوية مثل معنى الحقل أو سياسة rollout؛ أدوات المخطط لا تعرف إن كان التطبيق يستخدم القيمة ضمن قواعد عمل.

ثبت fixtures من الإصدار السابق، ثم شغلها عبر generated code القديم والجديد. اختبر حذف حقل مع إعادة استخدام رقم الحقل، وتغيير النوع، وenum value جديدة، وpresence للحقول الاختيارية. على checker أن يحذر من إعادة استعمال field number لأن ذلك قد يفسر bytes القديمة بطريقة غير مقصودة. اكتب تقريراً يذكر schema compiler وإصدار runtime وإعدادات البناء.

حدود التوافق والتسليم

فاحص المخطط لا يضمن توافق REST أو JSON أو source code في اللغات المولدة ولا يثبت أن إصدار عميل قديم ما زال منشوراً. بعض تغييرات Protobuf تصنف wire-compatible لكنها قد تقطع الاستخدام الدلالي أو تخسر قيمة عند التحويل. لذلك يلزم توثيق نوع serialization وقواعد كل منصة. سلم تقرير فروق، fixtures قابلة لإعادة التشغيل، وقائمة حالات «تحتاج قراراً بشرياً». يمكن لفريق مشاريع التخرج في هندسة البرمجيات أن يضيف CI check كمرحلة اختيارية، لكن يبدأ محلياً حتى لا يمنع تغييراً مقصوداً بلا مسار استثناء. اذكر القيود بدلاً من وعد «توافق مضمون».