نظامك القديم: نصلّحه ولا نبنيه من الأول؟

نظامك القديم: نصلّحه ولا نبنيه من الأول؟

عندك نظام شغال من 7 سنين. بطيء، شكله قديم، وكل تعديل بسيط بياخد أسبوع ويكسر حاجة تانية. السؤال اللي بيتكرر: نرقّع ولا نبني من الأول؟

القرار ده مكلف في الاتجاهين، فخليني أدّيك معايير بدل آراء.

الأول: «قديم» مش عيب في حد ذاته

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

علامات إن الترقيع بقى استنزاف

1. كل تعديل بيكسر حاجة تانية. ده أوضح مؤشر. معناه إن الأجزاء متشابكة لدرجة إن محدش يقدر يتوقع أثر أي تغيير.

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

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

4. تكلفة الصيانة السنوية بقت نسبة كبيرة من تكلفة البناء الجديد. لو بتدفع سنوياً 40% من تكلفة نظام جديد عشان تبقيه عايش — الحسبة واضحة.

5. النظام بقى يمنعك تكبّر. عايز تفتح فرع جديد والنظام مابيدعمش فروع. عايز تطبيق موبايل والنظام مافيهوش API. هنا النظام بقى سقف لشغلك.

علامات إن الترقيع لسه أذكى

- النظام مستقر والمشاكل محددة (بطء في شاشة معينة، تقرير ناقص). - التقنية لسه مدعومة وفيه مبرمجين. - محتاج مميزات جديدة محدودة تقدر تتبني كوحدات منفصلة. - بياناتك سليمة ومنظمة.

في الحالات دي، إعادة البناء بتبقى مغامرة غير مبررة.

الطريق الوسط اللي بننصح بيه كتير

مش لازم تختار بين «نسيب كله» و«نهد كله». فيه طريقة تالتة بتشتغل كويس جداً: الاستبدال التدريجي.

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

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

ليه ده أأمن؟ لأن شغلك مابيقفش، ولو حصلت مشكلة بترجع للوحدة القديمة، والتكلفة بتتوزّع على شهور بدل دفعة واحدة.

عيبه: بياخد وقت أطول من البناء الكامل، ومحتاج تخطيط أدق.

أخطر جزء: البيانات

مهما كان قرارك، البيانات هي أهم أصل عندك. وفي عمليات النقل دي أغلب الكوارث بتحصل هنا.

القواعد اللي مابنكسرهاش: - نسخة احتياطية كاملة قبل أي خطوة، مُختبرة بالاستعادة. - النقل بيتجرّب على نسخة تجريبية الأول، مش على الحقيقي. - مراجعة عيّنات بعد النقل: الأرصدة تطابق؟ عدد السجلات صح؟ التواريخ مظبوطة؟ - النظام القديم يفضل شغال للقراءة فترة بعد النقل.

الخلاصة

اسأل: النظام ده بيمنعني أكبر؟ وتكلفة إبقائه عايش قد إيه مقارنة ببديله؟ لو الإجابة إنه سقف لشغلك والصيانة بتستنزفك — الاستبدال التدريجي هو أأمن طريق. ولو عايز تقييم محايد لحالة نظامك الحالي قبل ما تقرر، ده شغل بنعمله وبنطلع منه بتوصية صريحة حتى لو كانت «سيبه زي ما هو».

مقالات أخرى

نظام ERP مخصص: التكلفة الحقيقية ومدة التنفيذ بصراحة ←Native ولا Flutter؟ اختيار تقنية تطبيقك من غير ندم ←كراسة المواصفات: الورقة اللي بتفرق بين مشروع ناجح ومشروع بيتأخر سنة ←

عندك فكرة مشروع؟ خلّينا نحوّلها إلى كود يشتغل.