تحديث نظامنا القديم كان كابوساً: كيف أنقذنا نمط ‘الخنق التدريجي’ (Strangler Fig) من جحيم إعادة البناء الكارثية؟

السلام عليكم يا جماعة،

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

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

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

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

ما هو نمط الخنق التدريجي (Strangler Fig Pattern)؟

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

في عالم البرمجيات، الفكرة هي نفسها: بدل ما تهدم النظام القديم (الشجرة القديمة) وتبني واحد جديد من الصفر، أنت بتبني النظام الجديد (التين الخانق) حول النظام القديم. بتبدأ “تخنق” أجزاء من النظام القديم بشكل تدريجي، قطعة ورا قطعة، لحد ما النظام الجديد يسيطر بالكامل، والنظام القديم “يموت” بسلام وبدون ما حدا يحس عليه.

لماذا إعادة البناء الكاملة (Big Bang Rewrite) فكرة سيئة غالباً؟

تجربتنا مع مشروع “العنقاء” علمتنا بالطريقة الصعبة ليش إعادة البناء الكاملة، أو اللي بنسميها “Big Bang”، هي وصفة شبه مؤكدة للكارثة. الأسباب كثيرة:

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

باختصار، إعادة البناء الكاملة مثل محاولة تغيير محرك طائرة وهي في الجو. ممكن تنجح، بس احتمالات الفشل كارثية.

كيف طبقنا نمط الخنق: خطوات عملية

طيب يا أبو عمر، حكيت كثير، فرجينا الشغل. كيف طبقنا هذا الحكي على أرض الواقع؟ الموضوع تم على مراحل منظمة.

الخطوة الأولى: بناء الواجهة الخانقة (The Strangler Facade)

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

هذا الجدار هو نقطة التحكم تبعتنا. ممكن يكون تطبيق بسيط جداً أو حتى مجرد إعدادات في Reverse Proxy مثل Nginx أو Cloudflare Workers.

مثال بسيط جداً لواجهة خانقة باستخدام Express.js (Node.js):

// proxy-facade.js
const express = require('express');
const { createProxyMiddleware } = require('http-proxy-middleware');

const app = express();

// عناوين الأنظمة
const LEGACY_SYSTEM_URL = 'http://legacy-api.internal:8080';
const NEW_USERS_SERVICE_URL = 'http://new-users-service.internal:3001';

// --- مرحلة الخنق ---

// 1. طلبات جزئية المستخدمين الجديدة تذهب للخدمة الجديدة
// أي طلب يبدأ بـ /api/v2/users سيتم توجيهه للخدمة المصغرة الجديدة
app.use('/api/v2/users', createProxyMiddleware({ 
    target: NEW_USERS_SERVICE_URL, 
    changeOrigin: true,
    pathRewrite: {
        '^/api/v2/users': '/users', // نزيل /api/v2 من الرابط قبل إرساله للخدمة الجديدة
    },
}));

// 2. أي طلب آخر يذهب للنظام القديم كالمعتاد
// هذا هو الوضع الافتراضي
app.use('/', createProxyMiddleware({ 
    target: LEGACY_SYSTEM_URL, 
    changeOrigin: true 
}));

app.listen(80, () => {
    console.log('Strangler Facade is running on port 80');
});

لاحظوا في الكود كيف أننا جهزنا الواجهة لتكون قادرة على توجيه مسارات معينة (مثل /api/v2/users) للخدمة الجديدة، بينما كل شيء آخر لا يزال يذهب للنظام القديم. في البداية، بيكون كل التوجيه للنظام القديم، ثم نبدأ بإضافة قواعد التوجيه للخدمات الجديدة واحدة تلو الأخرى.

الخطوة الثانية: تحديد أول ضحية وبدء الخنق

هون بتيجي الحكمة. لازم تختار أول جزء بدك تهاجر (Migrate) للنظام الجديد بعناية.

نصيحة أبو عمر: يا جماعة، لا تبدأوا بأصعب وأعقد جزء في النظام! رح تفشلوا وتكرهوا حالكم. ابدأوا بشيء:

• منعزل نسبياً: له اعتماديات (dependencies) قليلة على باقي أجزاء النظام.
• قليل المخاطر: مثل صفحة عرض معلومات لا يمكن تعديلها (Read-only). مثلاً، عرض قائمة المنتجات أو صفحة “من نحن”.
• له قيمة واضحة: شيء يلاحظه المستخدم أو البيزنس ويشعر بالتحسن، هذا يعطيك دفعة معنوية وسياسية لإكمال المشروع.

في حالتنا، بدأنا بصفحة الملف الشخصي للمستخدم. بنينا خدمة مصغرة (microservice) جديدة ومستقلة مسؤولة فقط عن عرض بيانات المستخدم. بعد ما انتهينا منها واختبرناها جيداً، كل ما فعلناه هو إضافة سطر واحد في الواجهة الخانقة (Proxy) اللي بنيناها في الخطوة الأولى، لتوجيه كل الطلبات المتعلقة بالملف الشخصي إلى الخدمة الجديدة بدلاً من النظام القديم. المستخدم النهائي لم يشعر بأي شيء، سوى أن الصفحة أصبحت أسرع قليلاً ربما!

الخطوة الثالثة: التعايش ومزامنة البيانات

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

مثلاً، عندما بنينا خدمة المستخدمين الجديدة، كانت البيانات لا تزال في قاعدة بيانات النظام القديم. كان أمامنا عدة خيارات، ولكل منها مزايا وعيوب:

1. الخدمة الجديدة تقرأ من قاعدة البيانات القديمة مباشرة: حل سريع وسهل للتنفيذ، ولكنه سيء على المدى الطويل لأنه يربط النظام الجديد بالقديم بشكل وثيق. استخدمناه كحل مؤقت جداً.
2. إنشاء طبقة مزامنة بيانات (Data Synchronization Layer): هذا ما فعلناه. بنينا آلية بسيطة تقوم بنسخ أي تغيير على بيانات المستخدمين من قاعدة البيانات القديمة إلى قاعدة البيانات الجديدة الخاصة بالخدمة المصغرة. هذا سمح للخدمة الجديدة بأن تكون مستقلة تماماً.
3. استدعاءات API بين الأنظمة: ممكن للخدمة الجديدة أن تستدعي API في النظام القديم للحصول على بيانات لا تملكها بعد، والعكس صحيح. هذا يسمى نمط “Anti-Corruption Layer” وهو حل نظيف جداً.

تحدي البيانات هو قلب عملية التحديث، ويجب التخطيط له بعناية فائقة.

الخطوة الرابعة: التكرار حتى النهاية السعيدة

بعد نجاح خنق أول جزء، يصبح الأمر مثل لعبة الدومينو. نكرر نفس العملية:

1. نختار الجزء التالي من النظام القديم (الضحية التالية).
2. نبني له بديلاً كخدمة مصغرة حديثة.
3. نختبره بشكل جيد.
4. نحدّث الواجهة الخانقة لتوجيه الطلبات إليه.
5. نتعامل مع تحديات مزامنة البيانات.

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

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

نصائح من قلب الميدان

من تجربتي، هذه بعض النصائح العملية لتطبيق نمط الخنق بنجاح:

• المراقبة أهم من الكود نفسه: الواجهة الخانقة (Proxy) هي أهم جزء. يجب أن تسجل كل شيء وتراقب أداءها عن كثب. يجب أن تعرف فوراً إذا فشل توجيه طلب ما، وكم من الوقت استغرق، ولماذا. أدوات مثل Prometheus و Grafana و Elastic Stack كانت أفضل أصدقائنا.
• لا تبخل على الاختبارات: كل خدمة جديدة يجب أن تكون مغطاة بالاختبارات بشكل كامل (Unit, Integration, E2E). يجب أيضاً أن يكون لديك اختبارات على مستوى الواجهة الخانقة لتتأكد من أن قواعد التوجيه تعمل كما هو متوقع.
• اجعل خدماتك الجديدة مستقلة حقاً: تجنب الإغراء لمشاركة قاعدة البيانات. الاستقلالية هي سر قوة الخدمات المصغرة. استثمر الوقت في بناء آليات مزامنة بيانات نظيفة أو استخدم استدعاءات API.
• تواصل، تواصل، تواصل: اشرح الاستراتيجية للإدارة والبيزنس. أرهم التقدم التدريجي. احتفلوا بالانتصارات الصغيرة (خنق أول خدمة بنجاح هو انتصار كبير!). هذا يبني الثقة ويمنحك الدعم الذي تحتاجه للاستمرار.

الخلاصة: لا تهدم البيت القديم دفعة واحدة! 🏡

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

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

بالتوفيق في رحلات تحديثكم!