متى تحتاج إعادة التصميم؟ (When to Refactor)
نحتاج إلى إعادة التصميم (قاعدة المرات الثلاث):
- عند قيامك بأيّة مهمةٍ للمرّة الأولى، فالمهم هو إنجازها والحصول على النتيجة وحسب.
- لدى قيامك بمهمةٍ مشابهةٍ للمرّة الثانية قد ترفض بادئ الأمر فكرة التكرار ولكنك ستجد نفسك تقوم بنفس العمل!
- عند قيامك بالمهمة للمرّة الثالثة، ستحتاج إعادة التصميم.
عند إضافة ميّزةٍ (feature) جديدة
تساعد عملية إعادة التصميم (refactoring) على فهم شيفرات المبرمجين الآخرين بشكلٍ أفضل، وعند العمل على الشيفرة غير الجيدة لأحدهم فعليك بإعادة تصميمها أولًا، وهذا ضروريٌّ إذ يصبح التحكُّم بالشيفرة النظيفة (clean code) أكثر سهولةً، ولن تقتصر الفائدة عليك وحسب بل ستصبح المهمة أبسط لمَن بعدك أيضًا، وسيصبح كذلك من السهل إضافة ميّزاتٍ جديدةٍ، وبالتالي فإنّ إجراء التغييرات سيكون أسهل بكثيرٍ مما كان عليه قبل إعادة التصميم.
عند إصلاح الأخطاء (bugs)
تقبع الأخطاء (bugs) في الشيفرات (تمامًا كما البقّ في الحياة الواقعيّة) في أكثر الأجزاء رداءةً وظلامًا، وعندما تكون الشيفرة نظيفةً فستتَّضح الأخطاء بجهدٍ ووقتٍ أقل، ويقدِّر المديرون (managers) العملية الاستباقية لإعادة التصميم لأنّها ستغني عن الحاجةَ لإعادة التصميم المُخصَّص لاحقًا، وأيّ شيءٍ يجعل المبرمج سعيدًا أكثر من المدير الراضي؟
أثناء مراجعة الشيفرة (code review)
إذ هي الفرصةُ الأخيرة لتوضيب الشيفرة قبل نشرها للعامّة، ومن الأفضل القيام بها مع مُحرِّر الشيفرة الأساسيّ، والذي بدوره سيوفِّر الكثير من الوقت أثناء حلِّ المشاكل السطحية البسيطة ويمكِّن من التفرُّغ لحلِّ المشاكل الأصعب.