كيف نقرر متى نقوم بإعادة الهيكلة ومتى نقوم بإعادة الكتابة
يواجه كل مطور هذه اللحظة.
قاعدة الكود بطيئة. إضافة الميزات تستغرق وقتاً طويلاً جداً. الموظفون الجدد يجدون صعوبة في فهم النظام. وفي النهاية، يقترح شخص ما إعادة كتابة النظام بالكامل.
ينقسم الفريق عادةً إلى مجموعتين. مجموعة تريد البدء من جديد، والمجموعة الأخرى تخشى فشل عمليات إعادة الكتابة السابقة. كلا الجانبين لديه وجهات نظر منطقية.
إعادة الكتابة ليست حلاً سحرياً. فغالباً ما تستغرق وقتاً أطول مما هو مخطط له. ستنتهي بصيانة نظامين في وقت واحد، وقد تكرر حتى نفس الأخطاء في النسخة الجديدة.
تكون إعادة الكتابة منطقية في هذه الحالات المحددة:
• نموذج البيانات (Data model) خاطئ بشكل أساسي بالنسبة للعمل. • التكنولوجيا قديمة ولم تعد تتلقى تحديثات أمنية. • تغيرت احتياجات العمل لدرجة أن النظام الأصلي أصبح عفا عليه الزمن. • لا أحد في الفريق الحالي يفهم كيفية عمل النظام.
حتى في هذه الحالات، لا تقم بعملية استبدال شاملة ومفاجئة (big bang replacement). استخدم نمط strangler fig pattern. قم ببناء النظام الجديد قطعة قطعة جنباً إلى جنب مع النظام القديم.
في معظم الأوقات، أنت تحتاج فعلياً إلى إعادة الهيكلة (Refactoring).
تكون إعادة الهيكلة هي الخيار الصحيح عندما:
• لا يزال بإمكانك إضافة ميزات، حتى لو كان ذلك ببطء. • الفريق يفهم الكود الحالي. • الفوضى تقتصر على وحدات (modules) معينة. • لا يمكن للعمل التوقف عن إصدار ميزات جديدة.
قبل أن تختار، اسأل لماذا أصبح الكود سيئاً.
إذا كانت المشكلة هي الديون التقنية (technical debt)، فقم بإعادة هيكلة الأجزاء الأسوأ. أما إذا كانت المشكلة هي نقص مراجعات الكود أو ثقافة عمل سيئة، فلن تساعد إعادة الكتابة؛ بل ستقوم فقط ببناء فوضى جديدة بنفس العادات القديمة.
اطرح هذه الأسئلة قبل أن تقرر:
• هل يمكننا إصلاح الأجزاء الأسوأ بشكل منعزل؟ • هل نموذج البيانات معطل بالنسبة لاحتياجات العمل الحالية؟ • ما هي المعرفة التي سنفقدها إذا بدأنا من جديد؟ • هل يتمتع العمل بالاستقرار الكافي للتعامل مع فترة انتقال طويلة؟
البدء من جديد شعور جيد، لكن إنهاء عملية إعادة الكتابة هو الجزء الصعب. في معظم الأوقات، تكون خطة إعادة الهيكلة المنظمة أكثر أماناً وفعالية.
المصدر: https://dev.to/daviefano/how-we-decide-when-to-refactor-and-when-to-rewrite-40pk