كل مدير تقني (CTO) قابلته وخاض تجربة إعادة كتابة على طريقة "الانفجار الكبير" يروي القصة نفسها بندبةٍ مختلفة قليلًا. مدةٌ مُقدَّرة بثمانية عشر شهرًا، وتسليمٌ فعليّ بعد واحد وثلاثين. يُطلَق النظام الجديد أخيرًا، وخلال أسبوع يكتشف أحدهم أن النظام القديم كان لا يزال يعالج حالة ضريبية استثنائية لم يوثّقها أحد منذ عام 2014. إعادة الكتابة التي كان يُفترض بها أن تُحرِّر الأعمال جمّدتها بدلًا من ذلك عامين كاملين.
ثمّة طريقة أفضل، وهي ليست جديدة. أطلق عليها مارتن فاولر اسم شجرة التين الخانقة (strangler fig) — نبتةٌ تنمو حول شجرةٍ مُضيفة، فرعًا تلو فرع، حتى تختفي الشجرة الأصلية بهدوء ذات يوم فتقف التينة وحدها. وبالطريقة نفسها تُحدِّث أنظمتك: تدريجيًا، في بيئة الإنتاج، والنظام القديم يعمل طوال الوقت.
لماذا يفشل الانفجار الكبير مرّة بعد أخرى
المشكلة الجوهرية في إعادة الكتابة الكاملة ليست في الكفاءة التقنية، بل في أنك مُطالَبٌ بإعادة إنتاج سنواتٍ من منطق الأعمال المتراكم — معظمه غير موثَّق، وبعضه يحمل العبء كلّه — بينما الهدف نفسه لا يكفّ عن التحرّك. فالأعمال لا تتوقف انتظارًا لإعادة كتابتك: تصدر تشريعات جديدة، ويطرح منافسٌ ميزةً ما، ويُرقَّع النظام القديم، فإذا بمواصفاتك "المجمّدة" قد باتت خاطئة قبل أن تبدأ.
وثمّة أيضًا واقعٌ قاسٍ يتعلق بالتدفق النقدي. فإعادة الكتابة على طريقة الانفجار الكبير تُقدّم قيمةً صفرًا حتى يوم إطلاقها. تنفق ثمانية عشر شهرًا تحرق فيها الميزانية ورأس المال السياسي قبل أن يلمس مستخدمٌ واحد أي فرق. وإذا تبدّلت القيادة أو تحوّل السوق قبل ذلك اليوم، مات المشروع وهو نصف مبنيّ — فتجد نفسك تصون نظامين بدلًا من واحد.
كيف تعمل شجرة التين الخانقة فعليًا
بدلًا من استبدال كل شيء دفعةً واحدة، تضع طبقة توجيه (routing layer) أمام النظام القديم، وتنتزع قدرةً واحدة في كل مرة. كل شريحة تنتقل إلى المنصة الجديدة، ويُتحقَّق منها في الإنتاج، وتبدأ بحمل حركة مرور حقيقية. فيتقلّص النظام الأحادي (monolith) القديم شيئًا فشيئًا، والقيمة تُسلَّم على نحوٍ متواصل.
والآلية عادةً واجهة (façade) أو وكيل (proxy) — بوابة واجهات برمجية (API gateway)، أو وكيل عكسي (reverse proxy)، وأحيانًا مجرّد خدمة توجيه خفيفة — تتوسّط بين عملائك والنظام القديم. فالطلبات التي لا تعرف بعدُ كيف تعالجها تُمرَّر مباشرةً إلى الواجهة الخلفية القديمة، أما طلبات القدرات التي جرى ترحيلها فتذهب إلى الخدمة الجديدة، والمُستدعون لا يشعرون بالفرق أبدًا.
الهدف في أي شهرٍ بعينه ليس "اكتملت إعادة الكتابة"، بل "قدرةٌ إضافية تعمل الآن في النظام الجديد، في الإنتاج، ولم يتعطّل شيء".
تسلسلٌ ملموس
- القياس أولًا. ضَع الواجهة في موضعها ووجّه 100% من حركة المرور عبرها إلى النظام القديم، دون تغيير أي شيء آخر. هذه الخطوة وحدها تقلّل مخاطر كل ما يليها.
- اختَر ورقةً، لا الجذع. ابدأ بقدرةٍ ضيّقة النطاق قليلة الاعتماديات — الإشعارات، أو توليد ملفات PDF، أو نقطة نهاية للتقارير — لا نواة الفوترة.
- شغّل النظامين معًا، وقارن المخرجات. في المسارات الحرجة، استخدم نمط التشغيل الظلّي أو المتوازي (shadow / parallel-run): أرسل الطلب إلى القديم والجديد معًا، وقدّم نتيجة القديم، وسجّل أي تباين. هكذا تكتشف الحالة الضريبية الاستثنائية غير الموثّقة قبل أن تصل إلى أي عميل.
- حوّل تدريجيًا. انقل 1%، ثم 10%، ثم 50% من حركة المرور عبر راية ميزة (feature flag)، وتراجَع خلال ثوانٍ إذا ارتفع معدل الأخطاء.
- احذف الكود القديم. هذه الخطوة غير قابلة للتفاوض، وهي التي تتخطاها الفرق دائمًا. فإن لم تُحِل المسار القديم إلى التقاعد قطّ، تكون قد أضفت تعقيدًا، لا أزلته.
أين يسوء الأمر
النمط ليس سحرًا، وقد رأيت فرقًا تحوّله إلى فوضى. وأكثر صور الفشل شيوعًا هي الخانق الذي لا يخنق أبدًا: تُبنى قدرات جديدة، لكن لا أحد يموّل حذف القديمة، فتُشغّل نظامين إلى ما لا نهاية وتدفع التكلفة مضاعفة.
والثاني هو جاذبية قاعدة البيانات المشتركة. فإذا كانت الخدمة الجديدة والنظام الأحادي القديم يقرآن ويكتبان في الجداول نفسها، فأنت لم تفصل شيئًا — بل أضفت قفزة شبكية فحسب. وفكّ تشابك ملكية البيانات هو الجزء الأصعب في هذا العمل، أصعب من الكود نفسه، فخصّص له ميزانية. وقد تحتاج أحيانًا إلى فترة من الكتابة المزدوجة (dual-writes) وطبقة مزامنة تنوي التخلص منها بالكامل لاحقًا.
والثالث هو البدء بالجذع. تندفع الفرق بحماسٍ فتستهدف أكثر الوحدات ترويعًا ومركزيةً لإثبات جدوى النهج، فيكون أول ترحيلٍ لها هو الأخطر أيضًا. اكسب الثقة عند الأطراف أولًا.
من أين تبدأ يوم الاثنين
لا تحتاج إلى برنامج تحوّلٍ أو بند ميزانية جديد كي تبدأ. هذا الأسبوع، افعل ثلاثة أشياء: ارسم خريطة الاعتماديات الحقيقية لنظامك الأحادي — لا مخطط المعمارية المعلّق في الويكي، بل الخريطة الفعلية. ثم ضَع وكيلًا أو بوابةً أمامه ووجّه كل حركة المرور عبره دون أي تغيير، لتحصل على خطّ أساسٍ تنطلق منه. ثم اختر أكثر القدرات عزلةً لديك وانقلها وحدها، من طرفٍ إلى طرف، بما في ذلك حذف الكود الذي حلّت محله.
التحديث ليس حدثًا تنجو منه، بل عادةٌ تبنيها. فالفرق التي تنجح تتعامل مع النظام القديم بوصفه شيئًا تُحيله إلى التقاعد شريحةً صادقةً في كل مرة — ولا تدع التينة تتوقف عن النمو أبدًا.
تأمّل معماريتك اليوم: ما أصغر شيءٍ يمكنك خنقه بأمان أولًا؟