ما هو نمط شجرة الخنّاق وكيف يساعد في إدارة الأنظمة البرمجية القديمة؟

مقدمة: لماذا تصبح الشيفرة القديمة عبئاً بمرور الوقت؟

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

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

من أكثر الأساليب فعالية في هذا السياق نمط Strangler Fig Pattern، وهو نهج عملي يتيح تحديث الأنظمة القديمة بشكل تدريجي وآمن.

ما المقصود بشجرة الخنّاق؟

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

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

ما هو نمط Strangler Fig Pattern في البرمجة؟

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

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

لماذا تكون إعادة الكتابة الشاملة خطيرة؟

عندما يتم اختيار أسلوب Big Bang Rewrite، أي إعادة كتابة كل شيء ثم إطلاقه دفعة واحدة، تظهر تحديات كبيرة، من أبرزها:

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

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

المشكلة الأهم: كيف تنقل المستخدمين دون إرباكهم؟

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

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

لماذا نستخدم هذا النمط لإدارة الشيفرة القديمة؟

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

التدفق العام للعمل

1. إضافة جزء جديد إلى النظام دون تفعيله فوراً.
2. تشغيل الجزء الجديد بجانب الجزء القديم.
3. استخدام Feature Flags للتحكم في تفعيل السلوك الجديد أو تعطيله.
4. نقل المزيد من الوظائف تدريجياً إلى المكوّن الجديد.
5. حذف الشيفرة القديمة بعد اكتمال الترحيل.

بهذه الآلية، لا يحدث الانتقال في لحظة واحدة، بل يتم بشكل مدروس وقابل للقياس والرجوع عنه عند الحاجة.

أهم فوائد نمط Strangler Fig Pattern

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

هذا النمط لا يقدّم فقط حلاً تقنياً، بل يقدّم أيضاً نموذجاً عملياً لإدارة التغيير في الأنظمة الحية.

مثال عملي: إعادة بناء مزود مدفوعات ضخم

لنفترض أن لديك نظام مدفوعات يعمل ضمن تطبيق أحادي ضخم Monolithic Backend. هذا النظام يحتوي على ملايين الأسطر البرمجية، ونقاط وصول متعددة، وبنية معقدة تجعل تطويره أو ضم مطورين جدد إليه عملية مرهقة.

قد تكون دوافع إعادة البناء عديدة، مثل:

• ضعف الأداء.
• صعوبة فهم المعمارية الحالية.
• وجود شيفرة ميتة Dead Code.
• ارتفاع كلفة الصيانة.
• الحاجة إلى تحسين الاعتمادية وقابلية التوسع.

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

التحدي الحقيقي في هذا النوع من الأنظمة

أنت لا تريد إجبار مئات العملاء على التبديل بين Endpoints قديمة وجديدة كلما ظهرت مشكلة. كما أنك لا ترغب في تغيير العقود البرمجية Interfaces، بحيث تبقى المدخلات والمخرجات كما هي دون التأثير على التكاملات الحالية.

لهذا تحتاج إلى طبقة وسيطة ذكية تعزل العملاء عن التغييرات الداخلية.

الحل العملي: استخدام واجهة وسيطة Façade

يمكن بناء طبقة Façade تقوم باعتراض الطلبات المرسلة إلى نقاط الوصول القديمة، ثم تقرر إلى أين يتم توجيه كل طلب:

• إلى API الجديد إذا كانت هذه الوظيفة قد أُعيد بناؤها.
• أو إلى API القديم إذا لم يتم ترحيل هذا الجزء بعد.

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

كيف تبدو مراحل التطبيق؟

1. الاعتماد الكامل على النظام القديم في البداية.
2. بناء خدمة أو API جديد لوظيفة محددة.
3. تشغيل الجديد والقديم معاً في الوقت نفسه.
4. التحكم في التحويل باستخدام Feature Flags.
5. توسيع نطاق الوظائف التي تنتقل إلى النظام الجديد تدريجياً.
6. إزالة المسار القديم نهائياً بعد اكتمال الترحيل.

بهذا المعنى، تحدث عملية “الخنق” البرمجي عندما تتناقص مسؤوليات النظام القديم تدريجياً، وتنتقل إلى النظام الجديد حتى يختفي القديم تماماً.

متى يكون هذا النمط مناسباً؟

يُعد هذا النهج مناسباً بشكل خاص في الحالات التالية:

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

ملاحظات مهمة قبل التنفيذ

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

ومن الأفضل أيضاً ألا يتحول التعايش بين النظامين إلى حالة دائمة؛ لأن الهدف من النمط هو الاستبدال التدريجي، لا إضافة طبقة تعقيد جديدة بلا نهاية.

الخلاصة التقنية

نمط Strangler Fig Pattern من أفضل الأساليب العملية لإدارة Legacy Code في الأنظمة الكبيرة والحساسة. قوته الحقيقية تكمن في أنه يحول مشروعاً شديد الخطورة إلى سلسلة خطوات صغيرة قابلة للاختبار والتحكم والتراجع. إذا طُبّق بطريقة صحيحة، فإنه يتيح تحديث البنية البرمجية دون تعطيل المستخدمين، ويمنح الفرق فرصة تحسين الجودة تدريجياً بدلاً من المقامرة بإعادة كتابة كاملة غير مضمونة النتائج.