نتائج البحث

قد يكون تطوير بعض الشيفرات مشكلةً حقيقيةً إذ عند إحداث أيّ تغييرٍ في جزءٍ منها لا بُدَّ وأن تتبعه عدّة تغييراتٍ أخرى في أجزاء متفرِّقة، وبالتالي سيصبح تطوير البرنامج شائكًا معقّدًا وبتكلفةٍ غير زهيدةٍ، من معوِّقات التغيير: التغيير المتشعِّب (divergent change) المشكلة: الحاجة لتغيير الكثير من التوابع التي لا علاقة لها بالأمر بمجرَّد إحداث أيّ تغيير في الصنف. الحل: عزل سلوك الصنف عبر إنشاء صنفٍ جديدٍ، أو دمج الأصناف عبر الوراثة وذلك باستخراج الصنف الأعلى (superclass) أو استخراج الصنف الفرعيّ عند وجود أصناف مختلفةٍ ...

ملاحظة قبل البدء إنّ مشكلة التغيير المتشعِّب هي المشكلة المعاكسة تمامًا لمشكلة تغيير الأصناف المتعدِّدة (Shotgun Surgery)، إذ إنّ التغيير المتشعِّب هو مجموع التغييرات الكثيرة التي تُجرَى في صنفٍ (class) واحدٍ، أما تغيير الأصناف المتعدِّدة فهو تغييرٌ واحدٌ يُجرَى في العديد من الأصناف. توصيف المشكلة الحاجة لتغيير الكثير من التوابع التي لا علاقة لها بالأمر بمجرَّد إحداث أيّ تغيير في الصنف (class)، فمثلًا؛ لدى إضافة منتجٍ جديدٍ عليك تعديل التوابع المسؤولة عن البحث عن المنتجات وعرضها وتنظيمها، وهذا مستهلكٌ للوقت ...

إنشاء التوابع تستهدف إعادة التصميم بشكل رئيسيٍّ إنشاء التوابع الصحيحة المناسبة، إذ تكون التوابع الطويلة سببًا للمشاكل في كثيرٍ من الحالات، وتجعل شيفرات بعض التوابع منطق التنفيذ (execution logic) غامضًا ويصبح التابع بهذا عصيَّ الفهم من جهةٍ وصعب التغييرٍ من جهة ثانية. يشمل هذا القسم من الحلول كلَّ ما يتعلق بالتوابع وإزالة التكرار (duplicates) في الشيفرة ليسمح بإجراء التطويرات المستقبليّة، وهذه التقنيات هي: استخراج التوابع (Extract Methods): والتي تتمثل بوجود أجزاء من الشيفرة يُمكن عزلها وتجميعها سويةً. دمج التوابع (Inline ...

الخاصية will-change في CSS تسمح للمطورين بأخبار المتصفحات ما هي التغييرات المتوقع إجراؤها على العنصر، لكي يتمكن المتصفح من ضبط تحسينات الأداء قبل حدوث التغيير، وهذه التحسينات ستزيد من استجابة الصفحة عبر القيام بالحسابات اللازمة قبل وقوع التغيير. بطاقة الخاصية القيمة الابتدائية auto تُطبَّق على جميع العناصر. قابلة للوراثة لا قابلة للحركة لا القيمة المحسوبة كما حُدِّدَت. /* كلمات محجوزة */ will-change: auto; will-change: scroll-position; will-change: contents; will-change: transform; /* <custom-ident> */ will-change: opacity; ...

ملاحظة قبل البدء إنّ مشكلة تغيير الأصناف المتعدِّدة هي المشكلة المعاكسة تمامًا لمشكلة التغيير المتشعِّب (Divergent Change)، إذ إنّ التغيير المتشعِّب هو مجموع التغييرات الكثيرة التي تُجرَى في صنفٍ (class) واحدٍ، أما تغيير الأصناف المتعدِّدة فهو تغييرٌ واحدٌ يُجرَى في العديد من الأصناف. توصيف المشكلة يتطلَّبُ أيُّ تعديلٍ تقوم به إجراءَ تغييراتٍ طفيفةٍ بأصناف (classes) متفرِّقة. أسبابها توزيع مهمةٍ واحدةٍ على الكثير من الأصناف، ويحدث هذا نتيجةً للتطبيق المفرط للتغيير المُتشعِّب (Divergent Change). وما الحل؟ نقل سلوك (behaviour) الأصناف إلى ...

‎.change( handler )‎ القيمة المعادة كائن jQuery. الوصف يُستخدَم التابع ‎.change()‎ في ربط مُعالِج الأحداث (event handler) لتغيير حدث JavaScript أو إطلاق هذا الحدث على عنصر ما. ‎.change( handler )‎ أضيفت في الإصدار: 1.0. handler دالة على الشكل ‎Function( Event eventObject )‎، وتُمثِّل الدالة التي ستُنفَّذ في كل مرة يُطلَق فيها الحدث. ‎.change( [eventData ], handler )‎ أضيفت في الإصدار: 1.4.3. eventData أي شيء (وهو نوع افتراضي مُستخدَم في jQuery للإشارة إلى إمكانيّة استخدام أي نوع)، ويُمثِّل كائن يحتوي على ...

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

المشكلة وجود كائن مرجع صغير جدًا نادرًا ما يتغيَّر لتبرير إدارة دورة حياته. الحل تحويله إلى كائن قيمة (value object). مثال قبل إعادة التصميم مخطط يوضح كيفية ارتباط الصنفين Currency و Customer: مخطط يوضح كيفية ارتباط الصنفين Currency و Customer. بعد إعادة التصميم إعادة تصميم المخطط السابق للتتحول العلاقة الرابطة للصنفين Currency و Customer إلى علاقة has a (أي بمجرد وجود كائن Customer فلا بد من وجود كائن Currency له). مخطط يوضح كيفية ارتباط الصنفين Currency و Customer بعلاقة has ...

المشكلة وجود العديد من النُسَخ المتماثلة من صنفٍ واحدٍ تحتاج إلى استبدال كائنٍ واحدٍ بها. الحل تحويل الكائنات المتماثلة إلى كائن مرجعي واحد. مثال قبل إعادة التصميم مخطط يوضح وجود العديد من النُسَخ المتماثلة من الصنف Order: مخطط يوضح وجود العديد من النُسَخ المتماثلة من صنفٍ Order. بعد إعادة التصميم تحويل الكائنات المتماثلة إلى كائن مرجعي واحد: تحويل الكائنات المتماثلة إلى كائن مرجعي واحد. لم إعادة التصميم؟ في العديد من الأنظمة، يمكن تصنيف الكائنات على أنها إمَّا قيم أو مراجع. ...

نحتاج إلى إعادة التصميم (قاعدة المرات الثلاث): عند قيامك بأيّة مهمةٍ للمرّة الأولى، فالمهم هو إنجازها والحصول على النتيجة وحسب. لدى قيامك بمهمةٍ مشابهةٍ للمرّة الثانية قد ترفض بادئ الأمر فكرة التكرار ولكنك ستجد نفسك تقوم بنفس العمل! عند قيامك بالمهمة للمرّة الثالثة، ستحتاج إعادة التصميم. عند إضافة ميّزةٍ (feature) جديدة تساعد عملية إعادة التصميم (refactoring) على فهم شيفرات المبرمجين الآخرين بشكلٍ أفضل، وعند العمل على الشيفرة غير الجيدة لأحدهم فعليك بإعادة تصميمها أولًا، وهذا ضروريٌّ إذ يصبح التحكُّم بالشيفرة ...