كنت جالسًا في غرفة الاجتماعات، أنظر إلى “المخطط” الذي رسمه المدير التقني على السبورة البيضاء. كان عبارة عن صندوق كبير كُتب عليه “النظام القديم”، وسهم ضخم يشير إلى صندوق آخر فارغ كُتب عليه “النظام الجديد”، وبينهما كلمة واحدة: “إعادة كتابة كاملة”. شعرت بقبضة باردة في معدتي. يا جماعة، مش هيك بتنحل الأمور!
هذه الصورة أعادتني سنوات إلى الوراء، إلى مشروع سابق انتهى بكارثة. شهور طويلة من العمل في الظلام، فريق منهك، وميزانية تجاوزت كل الحدود، وفي النهاية، لم يعمل “النظام الجديد” كما كان متوقعًا. كان درسًا قاسيًا تعلمته بالطريقة الصعبة: “إعادة الكتابة الكبرى” أو ما يعرف بـ “Big Bang Rewrite” هي وصفة شبه مؤكدة للفشل.
قاطعت الصمت في الغرفة وقلت: “يا جماعة الخير، اسمحولي أحكيلكم قصة عن شجرة التين الخانقة…”. نظر إلي الجميع باستغراب، لكن هذه القصة كانت مدخلنا لإنقاذ المشروع، وربما لإنقاذ عقولنا أيضًا.
ما هو “نمط التين الخانق” (Strangler Fig Pattern)؟
قبل أن تظنوا أني تحولت إلى مزارع، دعوني أوضح. “نمط التين الخانق” هو مصطلح صاغه الخبير البرمجي “مارتن فاولر”، مستلهمًا إياه من أشجار التين الخانقة في الغابات الاستوائية. هذه الأشجار تبدأ حياتها كبذرة صغيرة على أغصان شجرة قديمة وكبيرة. ثم تنمو جذورها ببطء نحو الأسفل، لتلتف حول الشجرة المضيفة وتتشبث بها. مع مرور الوقت، تصبح هذه الجذور قوية وسميكة، وتُشكل هيكلًا جديدًا حول الشجرة القديمة. في النهاية، تموت الشجرة الأصلية وتتحلل، تاركةً وراءها شجرة التين الجديدة، قوية ومتجذرة في مكانها.
في عالم البرمجيات، الفكرة مشابهة تمامًا. بدلًا من محاولة استبدال نظامك القديم (Monolith) دفعة واحدة في عملية محفوفة بالمخاطر، أنت تقوم ببناء النظام الجديد حوله تدريجيًا، قطعة قطعة، حتى يختفي النظام القديم تمامًا بشكل طبيعي.
“الهدف من نمط التين الخانق هو تقليل المخاطر بشكل كبير أثناء تحديث الأنظمة القديمة. بدلًا من قفزة عملاقة في الظلام، نحن نخطو خطوات صغيرة ومدروسة في النور.” – من دفتر ملاحظاتي
لماذا تفشل إعادة الكتابة الكبرى (Big Bang Rewrite)؟
قبل أن نتعمق في كيفية تطبيق هذا النمط، دعونا نتفق على سبب كون “إعادة الكتابة الكبرى” فكرة سيئة في 99% من الحالات:
- مخاطرة عالية جدًا: أنت تراهن بكل شيء على مشروع واحد ضخم. أي خطأ في التقديرات أو التنفيذ قد يؤدي إلى انهيار كل شيء.
- وقت طويل للوصول للسوق: قد يستغرق المشروع سنوات. بحلول وقت إطلاقه، قد تكون متطلبات العمل قد تغيرت، أو قد يكون منافسوك قد سبقوك.
- تجميد الميزات الجديدة: أثناء عملية إعادة الكتابة، غالبًا ما يتوقف تطوير أي ميزات جديدة في النظام القديم، مما يضر بالعمل.
- معنويات الفريق: المشاريع الطويلة التي لا نهاية لها مُحبطة للغاية. يشعر المطورون بأنهم يعملون في نفق لا يرون ضوءًا في نهايته.
كيف طبقنا نمط التين الخانق خطوة بخطوة؟
حسنًا، بعد أن أقنعت الفريق (والإدارة بصعوبة) بتجربة هذا النهج، بدأنا العمل. كانت رحلة، وليست سباق سرعة. إليكم الخطوات العملية التي اتبعناها:
الخطوة الأولى: تحديد نقاط الفصل وإنشاء “الواجهة” (The Façade)
أول وأهم خطوة هي السيطرة على تدفق الطلبات (Requests) إلى نظامك. لا يمكنك “خنق” شيء لا تسيطر عليه. قمنا بإنشاء “واجهة” أو “بروكسي عكسي” (Reverse Proxy) بسيط باستخدام Nginx ووضعناه أمام النظام القديم. أصبح هذا البروكسي هو نقطة الدخول الوحيدة لكل المستخدمين.
في البداية، كل ما فعله هذا البروكسي هو تمرير جميع الطلبات كما هي إلى النظام القديم. لم يلاحظ المستخدمون أي تغيير، لكن بالنسبة لنا، كان هذا هو مفتاح التحكم.
# مثال بسيط جداً لإعدادات Nginx
server {
listen 80;
server_name our-awesome-app.com;
location / {
# في البداية، كل شيء يذهب إلى النظام القديم
proxy_pass http://legacy_system_address:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
الخطوة الثانية: اختيار أول ضحية (أول خدمة جديدة)
نصيحتي الذهبية هنا: ابدأ بشيء صغير وسهل. لا تحاول أن تبدأ بأكثر جزء معقد في النظام. اختر ميزة شبه مستقلة وذات تأثير منخفض نسبيًا إذا حدث خطأ ما.
في حالتنا، اخترنا صفحة “ملف المستخدم” (User Profile). كانت صفحة قراءة بسيطة، والبيانات فيها لا تتغير كثيرًا. قمنا ببناء خدمة مصغرة (Microservice) جديدة باستخدام تقنيات حديثة (كانت فرصة رائعة للفريق لتعلم شيء جديد!). هذه الخدمة كانت مسؤولة عن شيء واحد فقط: جلب وعرض بيانات ملف المستخدم.
الخطوة الثالثة: تحويل المسار (Divert the Traffic)
هنا يبدأ السحر. عدنا إلى إعدادات Nginx وقمنا بإضافة قاعدة جديدة. قلنا له: “يا Nginx، أي طلب يأتي إلى المسار /api/profile، لا ترسله إلى النظام القديم، بل أرسله إلى خدمتنا المصغرة الجديدة”.
server {
listen 80;
server_name our-awesome-app.com;
# هذه القاعدة الجديدة!
location /api/profile {
proxy_pass http://new_profile_service_address:3000;
proxy_set_header Host $host;
}
# أي شيء آخر لا يزال يذهب إلى النظام القديم
location / {
proxy_pass http://legacy_system_address:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
بمجرد تطبيق هذا التغيير، أصبح المستخدمون الذين يزورون صفحة ملفهم الشخصي يستخدمون الكود الجديد دون أن يشعروا بذلك! لقد قمنا باستبدال أول قطعة من النظام القديم بنجاح، وبدون أي توقف في الخدمة (Zero Downtime).
الخطوة الرابعة: كرر العملية… على مهلك!
بعد نجاح الخطوة الأولى، ارتفعت معنويات الفريق. أصبح لدينا الآن نمط واضح للعمل. كنا نختار ميزة أخرى، مثل “إدارة الطلبات” (Order Management)، ونقوم ببناء خدمة مصغرة جديدة لها، ثم نحدث البروكسي لتحويل المسار إليها.
مع كل ميزة جديدة يتم “خنقها” واستبدالها:
- كان النظام الجديد ينمو ويكبر.
- كان النظام القديم يصغر ويضمر.
- كان الفريق يقدم قيمة حقيقية للمستخدمين بشكل مستمر.
- كنا قادرين على اختبار كل جزء جديد بشكل منفصل، مما قلل من المخاطر.
نصائح من “الختيار” (أبو عمر)
هذه الرحلة علمتني الكثير، وإليكم بعض النصائح العملية من وحي التجربة:
- قاعدة البيانات هي “الزعيم الأخير”: أصعب جزء في هذه العملية هو التعامل مع قاعدة البيانات المشتركة. في البداية، قد تسمح للخدمة الجديدة بالقراءة من قاعدة بيانات النظام القديم مباشرة. لكن على المدى الطويل، ستحتاج إلى استراتيجية لفصل البيانات. ابحث عن تقنيات مثل “Change Data Capture” أو “Event Sourcing” لمزامنة البيانات أثناء الفترة الانتقالية.
- لا تكن بطلاً: مرة أخرى، ابدأ بالشيء الأسهل. النجاحات الصغيرة المبكرة تبني الثقة والزخم للمهام الأصعب لاحقًا.
- المراقبة والتسجيل (Monitoring & Logging): بما أن نظامك أصبح موزعًا، فإن وجود نظام مركزي لمراقبة أداء الخدمات وتجميع سجلاتها (Logs) ليس رفاهية، بل ضرورة قصوى لتشخيص المشاكل بسرعة.
- التواصل هو المفتاح: اشرح هذا النمط للإدارة وأصحاب المصلحة. عندما يفهمون أنهم سيرون تحسينات تدريجية ومستمرة بدلاً من انتظار “الانفجار الكبير” الذي قد لا يأتي أبدًا، سيصبحون أكبر داعميك.
الخلاصة: تحديث الأنظمة ماراثون وليس سباق سرعة
في النهاية، وبعد أشهر من العمل المنهجي، نظرنا إلى الوراء لنجد أن النظام القديم أصبح مجرد هيكل فارغ. معظم الوظائف الحيوية أصبحت تعمل كخدمات مصغرة حديثة ومستقلة. لم نقم بإعادة كتابة كارثية، بل قمنا بعملية “زراعة” نظام جديد حول القديم، تمامًا مثل شجرة التين الخانقة.
هذا النمط ليس حلاً سحريًا، فهو يتطلب تخطيطًا وانضباطًا. لكنه يحول مهمة ضخمة ومخيفة إلى سلسلة من الانتصارات الصغيرة والمُدارة. إنه يمنحك المرونة لتبني تقنيات جديدة، ويحافظ على معنويات فريقك عالية، والأهم من ذلك، أنه يبقي نظامك يعمل ويخدم المستخدمين طوال فترة التحديث.
فيا صديقي المبرمج، إذا وجدت نفسك يومًا في غرفة اجتماعات أمام سبورة بيضاء تحمل مخطط “إعادة الكتابة الكبرى”، تذكر قصة شجرة التين، وكن أنت الصوت الذي يقول: “يا جماعة، فيه طريقة أحسن… شوي شوي.” 🌱
