متى يجب عليك إعادة هيكلة نظام قديم أو استبداله أو إيقاف تشغيله؟

Question

Accepted Answer

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

## دليل القرار

```text
REFACTOR (improve in place) when:
  - Core logic is sound; it's holding business value
  - Problems are localized; you can improve incrementally

REPLACE (rewrite/migrate) when:
  - It blocks important work and can't be incrementally fixed
  - Maintenance cost > rebuild cost over a sensible horizon
  - It's a growing security or reliability liability

RETIRE (remove entirely) when:
  - Its value no longer justifies any maintenance cost
  - Usage has dwindled; a simpler path exists
```

## احذر من فخ إعادة الكتابة

إعادة الكتابة الكاملة مغرية وغالباً ما تكون كارثية، فهي تستغرق وقتاً أطول من المتوقع، وتعيد تقديم الأخطاء القديمة، والنظام العامل يتحلل في هذه الأثناء. فضّل إعادة الهيكلة التدريجية أو استبدال strangler-fig. استخدم إعادة الكتابة الكاملة فقط عندما تكون المسارات التدريجية مغلقة حقاً.

## مثال ملموس

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

## مزلة

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

## لماذا يهم

إعادة الكتابة غير الضرورية تضيع سنوات وتعيد تقديم المشاكل المحلولة؛ النظام القديم المهمل يصبح مسؤولية موقوتة.

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