من الجحيم إلى النعيم: كيف أنقذ نمط ‘التين الخانق’ مشروعنا من كارثة تحديث المونوليث؟

القصة تبدأ في ليلة شتوية باردة… وفنجان القهوة الثالث

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

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

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

ما هو “الوحش” (Monolith) ولماذا هو كابوس؟

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

أعراض المرض المونوليثي:

  • الترابط الشديد (Tight Coupling): أي تغيير في جزء صغير قد يؤثر بشكل غير متوقع على أجزاء أخرى بعيدة كل البعد.
  • بطء عمليات التطوير والنشر: بناء واختبار ونشر التطبيق بأكمله يستغرق وقتاً طويلاً جداً، حتى لو كان التغيير بسيطاً.
  • صعوبة التوسع (Scalability): إذا كان لديك ضغط على جزء واحد من النظام (مثل خدمة البحث)، فعليك توسيع النظام بأكمله، مما يهدر الموارد.
  • التقييد التكنولوجي (Technology Lock-in): أنت عالق مع مجموعة التقنيات التي بُني بها النظام أول مرة. هل تريد تجربة لغة برمجة جديدة أو قاعدة بيانات أحدث؟ حظاً موفقاً!

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

فخ “الثورة الكبرى” (The Big Bang Rewrite)

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

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

كنا بحاجة إلى استراتيجية أكثر ذكاءً وأقل خطورة. استراتيجية تسمح لنا بالتحديث التدريجي، خطوة بخطوة. وهنا يأتي دور بطل قصتنا.

بطل القصة: نمط التين الخانق (Strangler Fig Pattern)

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

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

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

كيف يعمل النمط عملياً؟ الخطوات الثلاث الرئيسية

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

  1. التعريف (Identify): حدد جزءاً من النظام القديم تريد تحديثه. ابدأ بشيء بسيط وقليل المخاطر. في حالتنا، قررنا البدء بصفحة “ملف المستخدم الشخصي”.
  2. التحويل (Divert): أنشئ خدمة جديدة (Microservice) تؤدي هذه الوظيفة باستخدام التقنيات الحديثة. ثم، ضع “واجهة” أو “بروكسي” (Proxy/Facade) أمام النظام القديم. هذا البروكسي هو العقل المدبر، وظيفته هي توجيه الطلبات. في البداية، كل الطلبات تذهب للنظام القديم.
  3. الخنق (Strangle): قم بتعديل البروكسي ليوجه الطلبات المتعلقة بالوظيفة الجديدة (ملف المستخدم) إلى الخدمة الجديدة بدلاً من النظام القديم. الآن، أي طلب لـ /user/profile يذهب للخدمة الجديدة، بينما بقية الطلبات (مثل /products أو /orders) لا تزال تذهب إلى المونوليث القديم.

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

مثال عملي بالكود: خنق صفحة ملف المستخدم

لنفترض أن نظامنا القديم يعمل على http://legacy-system.com والنظام الجديد (الخدمة المصغرة للمستخدمين) يعمل على http://new-user-service.com.

سنستخدم بروكسي بسيط (يمكن بناؤه بـ Nginx, Envoy, أو حتى بـ Node.js/Express) ليكون الواجهة أمام المستخدمين.

هذا مثال بسيط جداً لكود البروكسي باستخدام Express في Node.js:


const express = require('express');
const { createProxyMiddleware } = require('http-proxy-middleware');

const app = express();

// الوجهة الأولى: الخدمة الجديدة لملفات المستخدمين
const userServiceProxy = createProxyMiddleware({
  target: 'http://new-user-service.com', // عنوان الخدمة الجديدة
  changeOrigin: true,
  pathRewrite: {
    '^/api/v2/users': '/api/users', // يمكن تعديل المسار إذا لزم الأمر
  },
});

// الوجهة الثانية (الافتراضية): النظام القديم (المونوليث)
const legacySystemProxy = createProxyMiddleware({
  target: 'http://legacy-system.com', // عنوان النظام القديم
  changeOrigin: true,
});

// الآن، نطبق منطق التوجيه
// أي طلب يبدأ بـ /api/v2/users سيذهب للخدمة الجديدة
app.use('/api/v2/users', userServiceProxy);

// أي طلب آخر سيذهب للنظام القديم
app.use('/', legacySystemProxy);

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

بهذا الكود البسيط، حققنا أول خطوة في الخنق. المستخدمون يتفاعلون مع البروكسي فقط، وهو الذي يقرر بهدوء أين يذهب كل طلب. مع مرور الوقت، نضيف المزيد من القواعد مثل هذه:


// ... بعد فترة، أضفنا خدمة جديدة للمنتجات
const productServiceProxy = createProxyMiddleware({ ... });
app.use('/api/v2/products', productServiceProxy);

// ... وهكذا

وبهذه الطريقة، قطعة قطعة، نُخرج الوظائف من المونوليث إلى خدمات جديدة مستقلة، دون توقف كبير أو مخاطرة عالية.

نصائح من كيس أبو عمر (خبرة عملية)

خلال رحلتنا هذه، تعلمنا بعض الدروس القاسية والمفيدة، إليكم خلاصة الزبدة:

  • ابدأ صغيراً وبشكل استراتيجي: لا تختر الجزء الأكثر تعقيداً في البداية. اختر وظيفة سهلة نسبياً وقليلة الاعتماديات لتكون أول انتصار لك وللفريق. هذا يرفع المعنويات ويثبت نجاعة الفكرة للإدارة.
  • الرصد والمراقبة هما عيناك: استثمر بقوة في أدوات المراقبة (Monitoring) وتسجيل الأحداث (Logging) منذ اليوم الأول. يجب أن تعرف ماذا يحدث في البروكسي، وفي الخدمة الجديدة، وفي النظام القديم. بدون هذه البيانات، أنت تقود وأنت أعمى.
  • لا تنسَ قاعدة البيانات: هذه هي أصعب جزئية في عملية الخنق. هل تشارك الخدمة الجديدة قاعدة بيانات المونوليث القديم مؤقتاً؟ أم تنقل البيانات؟ هذا قرار استراتيجي كبير ويحتاج تخطيطاً دقيقاً. هناك أنماط مثل (Database-per-Service) و(Shared Database) ولكل منها مزاياه وعيوبه في هذه المرحلة الانتقالية.
  • التواصل، ثم التواصل، ثم التواصل: هذه ليست مجرد مهمة تقنية. اشرح للإدارة ولأصحاب المصلحة (Stakeholders) ما تفعله ولماذا. وضح لهم أن هذه استراتيجية لتقليل المخاطر وتسريع الابتكار على المدى الطويل.
  • احتفل بالانتصارات الصغيرة: عندما تنجح في خنق أول جزء من النظام، احتفل مع الفريق! هذه الرحلة طويلة، والاحتفال بالنجاحات الصغيرة يبقي الجميع متحفزاً.

الخلاصة: رحلة وليست وجهة 🏁

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

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

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

أبو عمر

سجل دخولك لعمل نقاش تفاعلي

كافة المحادثات خاصة ولا يتم عرضها على الموقع نهائياً

آراء من النقاشات

لا توجد آراء منشورة بعد. كن أول من يشارك رأيه!

آخر المدونات

نصائح برمجية

كانت المدخلات غير المتوقعة تحطم تطبيقنا: كيف أنقذتنا ‘البرمجة الدفاعية’ من جحيم الانهيارات المفاجئة؟

أشارككم قصة حقيقية من قلب المعركة البرمجية، يوم كادت المدخلات العشوائية أن تقضي على تطبيقنا. اكتشفوا كيف أن تبني عقلية "البرمجة الدفاعية" لم يصلح الأخطاء...

12 مايو، 2026 قراءة المزيد
خوارزميات

كان التحقق من وجود البيانات يقتل قاعدة بياناتنا: كيف أنقذنا ‘فلتر بلوم’ (Bloom Filter) من جحيم الاستعلامات غير الضرورية؟

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

12 مايو، 2026 قراءة المزيد
تجربة المستخدم والابداع البصري

كانت واجهاتنا خليطاً من الفوضى: كيف أنقذنا ‘نظام التصميم’ (Design System) من جحيم عدم الاتساق؟

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

12 مايو، 2026 قراءة المزيد
برمجة وقواعد بيانات

من فوضى “حدّث على جهازك أولاً” إلى تنظيم الترحيل: كيف أنقذتنا أدوات Migration قواعد بياناتنا؟

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

12 مايو، 2026 قراءة المزيد
الشبكات والـ APIs

كانت إعادة المحاولة الشبكية تسبب كوارث: كيف أنقذنا ‘مفتاح عدم التكرار’ (Idempotency-Key) من جحيم العمليات المكررة؟

أشارككم قصة حقيقية من قلب المعركة البرمجية، حين كادت عمليات الدفع المكررة أن تدمر ثقة عملائنا. اكتشفوا كيف تحول "مفتاح عدم التكرار" (Idempotency-Key) من مفهوم...

12 مايو، 2026 قراءة المزيد
الحوسبة السحابية

كانت بيئاتنا السحابية فوضى: كيف أنقذتنا ‘البنية التحتية كود’ (IaC) من جحيم ‘الانحراف التكويني’؟

أشارككم قصة حقيقية من قلب المعاناة مع الخوادم، وكيف انتقلنا من الفوضى والتعديلات اليدوية العشوائية إلى عالم منظم يمكن التنبؤ به بفضل مفهوم "البنية التحتية...

12 مايو، 2026 قراءة المزيد
البودكاست