خطوات إعادة التصميم (Refactoring)
تجري عملية إعادة التصميم (refactoring) عبر عدّة خطواتٍ تُحدِث تغييرًا بسيطًا تدريجيًّا يجعل الشيفرة (مع كلِّ تغييرٍ) أفضل بقليلٍ، ولكنها لا توثر على أداء وفعاليّة البرنامج وتحافظ على استمرار عمله بشكلٍ سليمٍ، وتتلخص إعادة التصميم بالخطوات الآتية:
الحصول على شيفرةٍ نظيفة (clean code)
إن لم تصبح الشيفرة أنظف من بعد إعادة التصميم فهذا هدرٌ للوقت، ولكن ما السبب؟
- يحدث كثيرًا أن تحيد عن سياق إعادة التصميم بتغييراتٍ تدريجيّة صغيرةٍ لتتجه نحو إجراء تغييرٍ كبيرٍ واحدٍ! وهذا خطأ ومن السهل الوقوع به ولاسيّما بوجود تقييدٍ زمنيّ (time limit).
- أو قد يعود السبب لكون الشيفرة رديئةً جدًا بالأصل، ومهما بذلت من جهدٍ فستبقى الشيفرة كارثيةً، وبهذه الحالة لا بُدَّ من إعادة كتابة أجزاء بأكملها من الشيفرة، ولكن قبل القيام بمثل هذه الخطوة عليك أولًا كتابة الاختبارات اللازمة والتأكُّد من توفُّر الوقت الكافي، وإن لم يتحقَّق لك ذلك فلا جدوى من البدء بها.
لا مهام وظيفيّة (functionality) جديدة أثناء إعادة التصميم
إذ يخلط الكثيرون ما بين إعادة التصميم (refactoring) والتطوير المباشر للميّزات الجديدة (features)؛ هما مهمتان مختلفتان ومن الضروري الفصلُ بينهما (على الصعيد الفرديّ بأقلّ تقدير).
اجتياز كافة الاختبارات السابقة
قد يحدث خللٌ ما أثناء إجراء الاختبارات بعد إعادة التصميم على الرغم من اجتياز الشيفرة لها سابقًا (قبل إعادة التصميم)، ويُعزى هذا لسببين:
- وجودُ مشكلةٍ بعملية إعادة التصميم: وهذه الحالة يسيرةٌ جدًا، وإصلاحُ الخطأ -من بعد كشفه- كفيلٌ بحل المشكلة.
- كونُ الاختبارات منخفضة المستوى (low-level): كأن يكون الاختبار مُخصَّصًا للتوابع الخاصّة (private methods) للأصناف (classes)، وبهذه الحالة فإنّ المشكلة تكمُن بالاختبارات بحدِّ ذاتها؛ فإما أن يُعاد تصميم تلك الاختبارات أو أن تُكتبَ اختبارات جديدة عالية المستوى (high-level)، ويكون الحلُّ الأفضل بالاعتماد بالأصل على نمط الاختبارات BDD (أي اختبارات التطوير وفق السلوك [Behavior-Driven Development]).