نظامنا القديم كان قلعة حصينة: كيف أنقذنا ‘نمط التين الخانق’ من جحيم التحديثات المستحيلة؟

يا جماعة الخير، السلام عليكم ورحمة الله. معكم أخوكم أبو عمر.

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

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

ما هو “نمط التين الخانق” (Strangler Fig Pattern)؟

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

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

لماذا نحتاج هذا النمط؟ مشكلة القلاع القديمة

الأنظمة القديمة، أو ما يسمى بالـ Legacy Systems، تشترك في مجموعة من المشاكل اللي بتخلي الحياة صعبة على المطورين والشركة كلها:

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

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

خطوات تطبيق نمط التين الخانق: دليل أبو عمر العملي

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

الخطوة الأولى: تحديد الواجهة (The Façade)

أول وأهم خطوة هي بناء “بوابة” أو “واجهة” أمام نظامك القديم. هاي البوابة، اللي بنسميها تقنياً Proxy أو API Gateway، هي اللي رح تستقبل كل الطلبات من المستخدمين أو الأنظمة الأخرى. في البداية، كل وظيفتها هي إنها تمرر الطلبات زي ما هي للنظام القديم.

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

كمثال بسيط جداً باستخدام Nginx كـ Reverse Proxy:

# nginx.conf
server {
    listen 80;
    server_name www.your-awesome-app.com;

    location / {
        # في البداية، كل الطلبات تذهب للنظام القديم
        proxy_pass http://legacy_monolith_system:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

بهذا الإعداد البسيط، صرت أنت المتحكم. النظام القديم صار ورا الكواليس.

الخطوة الثانية: “الخنق” الأول – اختيار أول خدمة

هنا يبدأ المرح. بدك تختار أول جزء من “القلعة” عشان تبني بداله خدمة جديدة ولامعة. كيف تختار؟

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

بعد ما تبني الخدمة الجديدة (ولتكن مثلاً خدمة إدارة المستخدمين `user-service`)، بترجع على البوابة (الـ Nginx Proxy) وبتعدّل التوجيه:

# nginx.conf (بعد التحديث الأول)
server {
    listen 80;
    server_name www.your-awesome-app.com;

    # الطلبات الخاصة بالمستخدمين تذهب للخدمة الجديدة
    location /api/users {
        proxy_pass http://new_user_service:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # باقي الطلبات ما زالت تذهب للنظام القديم
    location / {
        proxy_pass http://legacy_monolith_system:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

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

الخطوة الثالثة: التوسع والنمو (Rinse and Repeat)

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

التحدي الأكبر: البيانات!

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

• الاعتماد على واجهات برمجة التطبيقات (APIs): الخدمة الجديدة ممكن تقرأ البيانات اللي بتحتاجها من النظام القديم عن طريق API هو بيوفرها.
• قاعدة بيانات مشتركة (للمرحلة الانتقالية فقط!): ممكن الخدمة الجديدة والنظام القديم يقرأوا من نفس قاعدة البيانات. هذا حل سريع ولكنه خطير على المدى الطويل، فكن حذراً.
• بنية قائمة على الأحداث (Event-Driven): لما يصير تغيير في النظام القديم (مثلاً، إضافة منتج جديد)، النظام القديم يطلق “حدث” (Event). الخدمات الجديدة المهتمة بهذا الحدث بتلتقطه وبتحدّث بياناتها الخاصة. هذا هو الحل الأنظف والأكثر قابلية للتوسع.

الخطوة الرابعة: لحظة الحقيقة – إطفاء الأنوار على القلعة

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

في هاي اللحظة، وبكل فخر واعتزاز، بتقدر تعمل اجتماع، وتضغط الزر اللي بطفي سيرفر النظام القديم للأبد. صدقني، الشعور لا يوصف! شعور بالتحرر والنصر. لقد نجحت في استبدال قلعة قديمة مهترئة بمدينة حديثة ومرنة من الخدمات المصغرة (Microservices) دون أن توقف عجلة العمل ليوم واحد. 🎉

الخلاصة: من القلعة الحصينة إلى المدينة المرنة ✅

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

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

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