نتائج البحث

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

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

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

توصيف المشكلة استخدام بعضُ التوابع (methods) بياناتِ الكائنات (objects) الأخرى أكثر ممّا تستخدم بياناتِها ذاتَها. أسبابها تحدث هذه المشكلة عقب نقل الحقول (fields) إلى أصناف البيانات (data class)، إذ من الأفضل نقلُ التوابع المستخدِمة لتلك الحقول لذلك الصنف أيضًا. وما الحل؟ لنضع بالحسبان القاعدة الآتية: يجب أن تبقى الأجزاء التي تتغيَّر بآنٍ واحدٍ في المكان ذاته معًاولتحقيق ذلك: نقلُ التوابع (move methods) إلى المكان الأنسب في الشيفرة. عندما يستخدِم جزءٌ فقط من التابع بياناتِ كائنٍ (object) آخر، فالأفضل استخراجُ تابعٍ ...

تعيد الدالة كائن ضغط يمكن استخدامه لضغط البيانات التي لا يمكن وضعها في الذاكرة دفعة واحدة. البنية العامة zlib.compressobj(level=-1, method=DEFLATED, wbits=MAX_WBITS, memLevel=DEF_MEM_LEVEL, strategy=Z_DEFAULT_STRATEGY[, zdict]) ‎المعاملات level المعامل level هو عدد صحيح ضمن النطاق 0 إلى 9 أو ‎-1 ووظيفته هي التحكم في مستوى عملية الضغط، فالقيمة 1 تقابل المستوى(Z_BEST_SPEED) وهو الأسرع ويعطي أقل مقدار من الضغط، والقيمة 9تقابل المستوى(Z_BEST_COMPRESSION) وهو الأبطأ وينتج أكبر مقدار من الضغط. أما القيمة 0 فتقابل المستوى (Z_NO_COMPRESSION) فتعني عدم ضغط البيانات. القيمة الافتراضية لهذا المعامل ...

توصيف المشكلة وجود تركيبٍ معقَّدٍ لتعليمة switch أو عدّة تعليمات if متسلسلة. أسبابها ما يميِّز البرمجة كائنيّة التوجّه (OO) هو اعتمادها النادر على المعاملين switch و case، إذ تُوزَّع شيفرة switch بمواقع مختلفة من البرنامج بدلًا من تجمعيها في تعليمة switch واحدةٍ، وعند إضافة شرطٍ جديدٍ عليك إيجاد كافّة شيفرات switch لتعديلها، وكقاعدة عامّة: وجود تعليمة switch يعني أن عليك البدء بالتفكير بمبدأ التعدديّة الشكليّة (polymorphism). وما الحل؟ عزل تعليمة switch ووضعها بالصنف الصحيح عبر إنشاء صنفٍ (class) ونقل التابع ...

توصيف المشكلة وجود بعض الأصناف (classes) قليلة الاستخدام ولا أهمية لها في البرنامج، ويجدر التخلُّص منها إذ إنّ فهم وصيانة الأصناف يكلِّفان الوقت والجهد. أسبابها يكون تصميم الصنف بدايةً لأداء مهامٍ (functionality) معيّنة، ولكنّه قد يصبح صغيرًا لا أهميّة له من بعد الكثير من عمليات إعادة التصميم (refactoring). قد تُخصَّص بعض الأصناف لدعم التطوير المستقبلي للبرنامج (كالتخطيط المُسبق لميّزاتٍ ستُضاف لاحقًا)، وتصبح تلك الأصناف خاملةً عندما لا يحدث أيُّ تطويرٍ فيما بعد. وما الحل؟ تضمين الأصناف (inline classes) للعناصر (components) ...

ما هو رمز النوع؟ يحدث رمز النوع عندما يوجد مجموعة من الأرقام أو السلاسل النصية التي تشكل قائمة بالقيم المسموح بها لبعض العناصر بدلًا من استخدام نوع بيانات منفصل. وغالبًا ما تُعطَى هذه الأرقام والسلاسل المحددة أسماءً مفهومة عن طريق الثوابت، وهو السبب في استخدام هذه الرموز بشكل كبير. المشكلة يؤثر نوع مُرمَّز على سلوك البرنامج ولكن لا يمكن استخدام الأصناف الفرعية للتخلص منه. الحل استبدال رمز النوع بكائن حالة. إذا كان من الضروري استبدال قيمة حقل برمز النوع، فسيكون ...

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

توصيف المشكلة تظهر المشكلة بعدَّة جوانب: استخدام الحقول الأساسيّة (primitives) بدلًا من الكائنات (objects) لأداء المهامّ البسيطة (مثل: عمليات العملة [currency] والمجالات [ranges] والسلاسل النصية [strings] المُخصَّصة للأرقام الهاتفية، …إلخ.). استخدام الثوابت (constants) لترميز المعلومات (مثل استخدام الثابت USER_ADMIN_ROLE = 1 للدلالة على المستخدمين ذوي الصلاحيّات الإداريّة). استخدام الثوابت النصيّة (string constants) كأسماءٍ للحقول (fields) في مصفوفات البيانات (data arrays). أسبابها تنشأ هذه المشكلة بسبب العبارة المُدمِّرة التي يفكّر بها المبرمجون بلحظة ضعفٍ: "حقلٌ واحدٌ فقط، ولتخزين معلومةٍ بسيطةٍ وحسب!"ولأنهم ...