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

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

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

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

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

لماذا نهج “الانفجار العظيم” هو وصفة للكارثة؟

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

أفخاخ قاتلة في طريق الانفجار العظيم

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

المنقذ: نمط التين الخانق (Strangler Fig Pattern)

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

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

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

1. تحديد الحدود: ابحث عن جزء من النظام يمكن فصله بسهولة. غالباً ما يكون هذا الجزء وحدة وظيفية قائمة بذاتها، مثل إدارة المستخدمين، أو نظام الفواتير، أو قسم التقارير. ابدأ بشيء صغير ومنخفض المخاطر.
2. إنشاء الواجهة الخانقة (Strangler Facade): هذه هي أهم خطوة. نقوم بوضع طبقة وسيطة (مثل Reverse Proxy أو API Gateway) أمام النظام بأكمله. كل الطلبات من المستخدمين ستمر عبر هذه الواجهة أولاً. في البداية، كل ما تفعله هذه الواجهة هو تمرير كل الطلبات إلى النظام القديم كما هي.
3. التحويل التدريجي: الآن، ابدأ ببناء أول قطعة من النظام الجديد (مثلاً، خدمة مصغرة لإدارة المستخدمين). بعد أن تصبح جاهزة، قم بتعديل “الواجهة الخانقة” لتقوم بتوجيه الطلبات المتعلقة بالمستخدمين (مثل /api/users) إلى الخدمة الجديدة، بينما تستمر باقي الطلبات بالذهاب إلى النظام القديم.
4. التكرار والخنق: كرر العملية. اختر وحدة أخرى، ابنها في النظام الجديد، وعدّل الواجهة الخانقة لتوجيه الطلبات إليها. مع كل خطوة، يتقلص دور النظام القديم وتزيد وظائف النظام الجديد. وفي النهاية، لن يتبقى في النظام القديم أي وظيفة، وعندها يمكنك إطفاء الخادم الخاص به والاحتفال!

مثال عملي: خنق نظام إدارة محتوى قديم

لنفترض أن لدينا نظام إدارة محتوى قديم يعمل على legacy-app.internal، والمستخدمون يصلون إليه عبر www.my-blog.com. النظام مسؤول عن كل شيء: المقالات (/articles)، والملفات الشخصية للمستخدمين (/profile)، والتعليقات (/comments).

قررنا أن نبدأ بتحديث “الملفات الشخصية للمستخدمين” لأنها وحدة منفصلة نسبياً.

1. إعداد الواجهة الخانقة باستخدام Nginx

سنستخدم Nginx كـ Reverse Proxy. في البداية، سيبدو ملف الإعدادات بسيطاً جداً، حيث يقوم فقط بتمرير كل شيء للنظام القديم:

# /etc/nginx/sites-available/my-blog.com

server {
    listen 80;
    server_name www.my-blog.com;

    # في البداية، كل شيء يذهب إلى النظام القديم
    location / {
        proxy_pass http://legacy-app.internal;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

بهذه الخطوة، أصبح لدينا نقطة تحكم مركزية في كل حركة المرور.

2. بناء الخدمة الجديدة وتحويل المسار

الآن، قام فريقنا ببناء خدمة مصغرة جديدة (New Profile Service) تعمل على new-profile-service.internal وهي مسؤولة فقط عن كل ما يتعلق بـ /profile.

حان الوقت لتحديث إعدادات Nginx لـ “خنق” هذه الوظيفة من النظام القديم:

# /etc/nginx/sites-available/my-blog.com

server {
    listen 80;
    server_name www.my-blog.com;

    # (الخانق) - أي طلب يبدأ بـ /profile يذهب للخدمة الجديدة
    location /profile {
        proxy_pass http://new-profile-service.internal;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # أي شيء آخر يستمر بالذهاب للنظام القديم
    location / {
        proxy_pass http://legacy-app.internal;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

وهكذا! بكل بساطة، قمنا بأول عملية خنق ناجحة. المستخدمون لن يلاحظوا أي فرق، لكننا في الخلفية قمنا باستبدال جزء من النظام القديم بآخر جديد وحديث. نكرر هذه العملية مع /comments، ثم /articles، حتى يصبح بلوك location / فارغاً، وعندها نقول وداعاً لـ legacy-app.internal.

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

• قاعدة بيانات مشتركة (حل مؤقت ومحفوف بالمخاطر): يمكن للخدمة الجديدة القراءة والكتابة مباشرة من قاعدة بيانات النظام القديم. هذا يسهل البداية لكنه يخلق اقتراناً قوياً (tight coupling).
• واجهة برمجة تطبيقات (API) وسيطة: إذا كان النظام القديم يحتوي على APIs، يمكن للخدمة الجديدة استخدامها للوصول للبيانات. هذا أفضل بكثير.
• مزامنة البيانات: إنشاء آلية لمزامنة البيانات بين قاعدة البيانات القديمة والجديدة. هذا هو الحل الأكثر تعقيداً ولكنه الأكثر مرونة على المدى الطويل.

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

💡 نصائح أبو عمر الذهبية

من خلال تجربتي ومعاناتي مع “الختيار” و”فينيكس”، خرجت بهذه الدروس التي أتمنى أن تفيدكم:

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

الخلاصة: استراتيجية حكيمة بدلاً من حل سحري

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

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

فإذا كنتم تواجهون “ختياراً” في أنظمتكم، لا تفكروا في “الانفجار العظيم”. فكروا كشجرة التين، وابدأوا بالخنق التدريجي. الله يوفقكم في مشاريعكم! 👍