غيّر نظاماً قائماً بأمان
مكتملحافظ على العقود الحالية عند إدخال تغيير. راعِ برامج العميل القديمة والبيانات وترتيب النشر.
تحقّق من فهمكتعيد تسمية عمود في قاعدة البيانات وتحدّث التطبيق في الإصدار نفسه. ما الذي قد يفشل مع ذلك؟نفّذ التمرين
ما ستتعلّمه
- تحديد العقود التي قد يتأثر بها تغيير محلي في الشيفرة.
- شرح تغيير مرحلي بأسلوب التوسيع ثم الإزالة.
- التمييز بين التراجع عن الشيفرة واستعادة البيانات.
حدّد العقود المحيطة بالتغيير
للبرمجيات القائمة شيفرة تستدعيها وبيانات مخزّنة ومهام مجدولة وإجراءات تشغيلية. لا تظهر بعض التبعيات في الملف الذي تريد تعديله. وقد ينتج الوكيل تغييراً صحيحاً محلياً يخرق أحد هذه العقود.
قبل التنفيذ، حدّد المكوّنات التي تقرأ البيانات المتأثرة أو تكتبها. افحص المسارات ومهام الخلفية والتقارير والتكاملات الخارجية. تحقّق مما إذا كانت فرق أخرى أو إصدارات أقدم من برامج العميل تعتمد على السلوك الحالي.
اطلب من الوكيل عرض أدلته على خريطة العلاقات هذه. تُعد نتيجة البحث بداية مفيدة، لكن الاستدعاءات الديناميكية والمكوّنات الخارجية المستهلكة قد تحتاج إلى تأكيد المسؤول عن التبعية.
اجعل السلوك الحالي قابلاً للملاحظة
لوحدة ضعيفة التوثيق، أضف فحوصاً مركّزة للسلوك الذي يجب أن يبقى مستقراً. تصف هذه الفحوص العقد الحالي. ولا تثبت أن كل سلوك موجود مرغوب فيه.
إذا تعارض السلوك الحالي مع متطلب، فسجّل التعارض. لا تحافظ على عيب أمني لمجرد أن اختباراً وثّقه. احصل على القرار اللازم للتمييز بين السلوك المقصود والعيب.
استخدم بيانات اختبار واقعية وغير حساسة. أدرج أشكال البيانات القديمة والسجلات غير المكتملة حيث يمكن أن توجد. قد يخفي مخطط بيانات جديد مشاكل الترحيل إذا اختُبر فقط ببيانات أُنشئت حديثاً.
راجع الانتقال بين الإصدارات
تأمّل مثالاً خيالياً لإعادة التسمية من customer_name إلى display_name. قد تعطل إعادة التسمية الفورية نسخة قديمة من التطبيق أثناء النشر. لا يجعل تحديث الملفين في طلب دمج واحد عملية النشر ذرّية.
قد يحافظ نهج مرحلي على التوافق:
- أضف الحقل الجديد دون إزالة القديم.
- حدّد كيف تحافظ عمليات الكتابة الجديدة على اتساق القيم المطلوبة.
- استكمل قيم السجلات الموجودة بعملية يمكن إعادة تشغيلها.
- تحقّق من الاكتمال وسلوك المكوّنات القارئة.
- انقل المكوّنات القارئة إلى الحقل الجديد.
- لا تزل الحقل القديم إلا بعد انتهاء اعتماد مستهلكيه عليه.
تعتمد الطريقة الدقيقة على قاعدة البيانات وأنماط الكتابة. قد تسبب الكتابة المزدوجة عدم اتساق إذا فشلت إحدى العمليتين. وقد تلزم معاملة قاعدة بيانات أو طريقة مزامنة صريحة أخرى. لا تطبّق هذا المثال دون فحص ضمانات النظام.
يصف Martin Fowler هذا الانتقال العام بالتغيير المتوازي، ويُسمّى أيضاً التوسيع ثم الإزالة. الفكرة الأساسية هي انتقال متوافق قبل الإزالة.
خطّط للاستعادة منفصلة عن التراجع
يعيد التراجع عن الشيفرة إصداراً سابقاً من التطبيق. لكنه لا يعكس ترحيل البيانات تلقائياً. فقد لا يفهم الإصدار القديم البيانات الجديدة. وقد يزيل ترحيل هدّام معلومات لا يستطيع التراجع عن الشيفرة استعادتها.
حدّد إجراء الاستعادة لكل خطوة. قد يكون استئناف عملية استكمال قابلة لإعادة التشغيل آمناً. وقد يحتاج تحويل خاطئ إلى تصحيح من بيانات المصدر المحفوظة. وقد تحتاج عملية هدّامة إلى إجراء استعادة متحقق منه.
اسأل من يملك قرار الاستعادة وكم قد تستغرق. وتجنّب اعتبار «لدينا نسخ احتياطية» دليلاً على أن الاستعادة تلبي متطلب الخدمة.
أبقِ التغيير قابلاً للمراجعة
افصل التنظيف غير المرتبط بالمهمة عن التغيير الوظيفي. قدّم خطة التوافق ونتائج التحقق وشروط الإزالة في طلب الدمج. حدّد النقطة التي يصبح التراجع بعدها محتاجاً إلى عمل إضافي.
يمكن للوكيل المساعدة في فحص المكوّنات المستهلكة وإعداد شيفرة الترحيل. لكن يجب أن يقبل مسؤول محدد خطة الانتقال والاستعادة. التصميم النهائي جزء واحد فقط من التغيير الآمن.
نفّذ التمرين
اختر تغييراً صغيراً في حقل أو API. احصر كل المكوّنات التي تقرأ البيانات أو تكتبها، بما فيها مهام الخلفية. صف خطوة أولى تضيف دون حذف، وفحصاً للانتقال، وشرطاً للإزالة. حدّد الخطوة التي قد تمنع التراجع.
تنزيل ورقة العمل (Markdown)يؤدي إلغاء هذا الاختيار إلى حذف كل التقدم المحفوظ في هذا المتصفح.
يبقى تقدمك في هذا المتصفح. دون حساب أو تتبّع.