ما ترميش السيستم القديم: بدّله حتة حتة بالـ Strangler Fig

كل مهندس اشتغل على سيستم قديم جاله اليوم ده: الكود تقيل، وكل تعديل بياخد أسبوع، وتبدأ الفكرة تلحّ عليك: «إحنا نرميه ونكتبه من الصفر».

الفكرة دي ليها اسم: big-bang rewrite. وهي من أخطر القرارات اللي ممكن تاخدها في مشروع شغال.

ليه الكتابة من الصفر خطر؟

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

مارتن فاولر بيقول إنه شاف الخطة دي بتـ«go down in flames most of the time»، يعني بتولّع في أغلب المرات.

الاسم جاي منين؟

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

وده بالظبط اللي عايزين نعمله مع السيستم القديم: الجديد يكبر حواليه، لحد ما القديم ما يبقاش ليه لازمة.

بيشتغل إزاي في الكود؟

الفكرة كلها قايمة على طبقة صغيرة اسمها facade، بتتحط قدام السيستم القديم. فكّر فيها كإنها موظف الاستقبال: كل طلب بيعدي عليه، وهو اللي بيقرر الطلب ده يروح فين.

Users ──▶ Facade ──┬──▶ Legacy   (orders, invoices, ...)
                   └──▶ New      (reports)

والخطوات بالترتيب:

1. تحط الـ facade قدام القديم. في الأول بيبعت كل الطلبات للقديم، فمفيش حاجة اتغيرت عند المستخدم.
2. تختار حتة واحدة، مثلًا التقارير، وتكتبها service جديدة.
3. تقول للـ facade: طلبات التقارير ابعتها للجديد. وباقي الطلبات لسه بتروح للقديم.
4. تكرر ده حتة ورا حتة.
5. لما مفيش حاجة تعتمد على القديم، تطفيه.

المكسب إيه؟

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

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

إمتى ما تستخدموش؟

الـ pattern ده مش لكل حاجة. توثيق Microsoft للـ pattern بيقول إنه مش مناسب في حالتين:

• السيستم صغير، وتبديله كله مرة واحدة سهل. هنا الـ facade والتقسيم مجهود ملوش لازمة.
• مفيش طريقة تعترض الطلبات وتعدّيها على بوابة. لو المستخدمين أو الأنظمة التانية بيكلموا القديم بطريقة ما تقدرش تحط حاجة قدامها، الـ pattern مش هينفع.

وخلي بالك من حاجة مهمة: الـ facade بقى كل الطلبات بتعدي عليه. لو وقع، كل حاجة تقع. فلازم تصمّمه بحيث ما يبقاش single point of failure.

رأيي

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

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

المصادر

• Martin Fowler، Strangler Fig، 2024.
• Martin Fowler، Strangler Fig Application، النسخة الأصلية، 2004.
• Microsoft Azure Architecture Center، Strangler Fig pattern.