نتائج البحث

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

المشكلة تخزين نتيجة تعبيرٍ ما (expression) في متغيِّر محليٍّ (local variable) لاستخدامه لاحقًا في الشيفرة. الحل نقل التعبير بأكمله إلى تابعٍ (method) مستقلٍ يعيد نتيجته، وعندها سيكون استدعاء هذا التابع بديلًا عن استخدام المتغيِّر (variable)، ومن الممكن أيضًا دمج هذا التابع مع توابع أخرى عند الحاجة للقيام بذلك. مثال قبل إعادة التصميم نلاحظ في الشيفرة الآتية وجود متغيِّرٍ مؤقتٍ باسم basePrice لتخزين القيمة الناتجة عن تنفيذ التعبير الرياضيّ بمعامل الجداء (أي المعامل *)، وسيُستخدَم هذا المتغيِّر لاحقًا في الأجزاء الشرطيّة ...

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

المشكلة وجود متغيِّرٍ مؤقَّت (temporary) لحفظ قيمة تعبيرٍ (expression) بسيطٍ ولا شيء آخر سواه. الحل تبديل كلُّ مرجعيّةٍ (reference) للمتغيِّر ليحلَّ محلَّها التعبيرُ نفسه. مثال قبل إعادة التصميم نلاحظ في الشيفرة الآتية وجود متغيِّرٍ مؤقتٍ باسم basePrice لتخزين القيمة الناتجة عن تعبير استدعاء التابع order.basePrice()‎، والذي سيُستخدَم في التعليمة التالية لتعريفه: في لغة Java: boolean hasDiscount(Order order) { double basePrice = order.basePrice(); return basePrice > 1000; } في لغة #C: bool HasDiscount(Order order) { double basePrice = order.BasePrice(); return ...

مقدمة يوفّر Laravel Envoy صياغة نظيفة ومختزلة لتعريف المهام الشائعة وتشغيلها على الخوادم البعيدة (remote servers)، ويمكنك إعداد المهام بسهولة باستخدام صياغة نمط Blade للنشر، أوامر Artisan وغيرها. ويدعم Envoy في الوقت الحالي أنظمة تشغيل لينكس و ماك فقط. التثبيت ثبّت أولًا Envoy باستخدام أمر global require الخاص بالأمر Composer: composer global require laravel/envoy قد تتسبب مكتبات Composer العامة (global) في بعض الأحيان في حدوث تعارضات في الحزم، يمكنك في هذه الحالة استخدام مكتبة cgr والذي يعد بديلًا للأمر composer global ...

مقدمة يوفّر Laravel Envoy صياغة نظيفة ومختزلة لتعريف المهام الشائعة وتشغيلها على الخوادم البعيدة (remote servers)، ويمكنك إعداد المهام بسهولة باستخدام صياغة نمط Blade للنشر، أوامر Artisan وغيرها. ويدعم Envoy في الوقت الحالي أنظمة تشغيل لينكس و ماك فقط. التثبيت ثبّت أولًا Envoy باستخدام أمر global require الخاص بالأمر Composer: composer global require laravel/envoy قد تتسبب مكتبات Composer العامة (global) في بعض الأحيان في حدوث تعارضات في الحزم، يمكنك في هذه الحالة استخدام مكتبة cgr والذي يعد بديلًا للأمر composer global ...

المشكلة استدعاء تابع استعلام (query method) وتمرير نتائجه كمعاملات لتابع آخر، في حين أنه يمكن لهذا التابع استدعاء الاستعلام مباشرة. الحل بدلًا من تمرير القيمة من خلال المعامل، حاول وضع استدعاء الاستعلام داخل متن التابع. مثال قبل إعادة التصميم تخزين القيمة التي يعيدها كلٌّ من التابعين ()getSeasonalDiscount و ()getFees في متغير ثم تمريرها إلى التابع ()discountedPrice: في لغة Java: int basePrice = quantity * itemPrice; double seasonDiscount = this.getSeasonalDiscount(); double fees = this.getFees(); double finalPrice = discountedPrice(basePrice, seasonDiscount, fees); في لغة C#‎: int basePrice ...

المشكلة ينقسم التابع إلى أجزاء، كل منها يتم تشغيله اعتمادًا على قيمة المعامل. الحل استخراج الأجزاء الفردية من التابع إلى توابعها الخاصة واستدعائها بدلًا من استدعاء التابع الأصلي. مثال قبل إعادة التصميم وجود تابع يدعى ()setValue يضبط قيمة الارتفاع والعرض بناءً على تمرير سلسلة نصية صريحة بذلك: في لغة Java: void setValue(String name, int value) { if (name.equals("height")) { height = value; return; } if (name.equals("width")) { width ...

المشكلة لديك مُنشئ (constructor) معقد يقوم بما هو أكثر من مجرد وضع قيم المعامل في حقول الكائن. الحل إنشاء تابع تصميم واستخدامه لاستبدال استدعاءات المُنشئ. مثال قبل إعادة التصميم وجود منشئ معقد للصنف Employee: في لغة Java: class Employee { Employee(int type) { this.type = type; } //... } في لغة C#‎: public class Employee { public Employee(int type) { this.type = type; } //... } في لغة PHP: class ...

المشكلة إسناد قيمةٍ ما إلى أحد المعاملات (parameter) داخل التابع (method body). الحل استخدام متغيِّرٍ محليٍّ (local variable) بدلًا من المعامل. مثال قبل إعادة التصميم نلاحظ وجود عمليّة إسنادٍ (من بعد الإنقاص بمقدار 2) إلى معامل التابع الوارد باسم inputVal: في لغة Java: int discount(int inputVal, int quantity) { if (inputVal > 50) { inputVal -= 2; } //... } في لغة #C: int Discount(int inputVal, int quantity) { if (inputVal > 50) ...

المشكلة وجود متغيِّرٍ محليّ يُستخدَم لتخزين عدّة قيمٍ مؤقتةٍ (مرحليّة) داخل التابع. الحل استخدام متغيِّراتٍ منفصلةٍ ومستقلّةٍ للقيم المختلفة، بحيث يكون كلَُ متغيِّرٍ مسؤولًا عن تخزين البيانات لمهمةٍ واحدةٍ فقط. مثال قبل إعادة التصميم نلاحظ في الشيفرة الآتية استخدام المتغيِّر temp لتخزين ناتج كلِّ من تعبيريّ المحيط والمساحة: في لغة Java: double temp = 2 * (height + width); System.out.println(temp); temp = height * width; System.out.println(temp); في لغة #C: double temp = 2 * (height + width); Console.WriteLine(temp); temp = height * width; Console.WriteLine(temp); في لغة PHP: $temp ...

الانعكاس هو مجموعةٌ من مميّزات اللغة والمكتبات التي تسمح بمراقبة بُنية البرنامج أثناء التنفيذ، إذ تولي لغة Kotlin أهميةً كبرى لكلٍّ من الدوال (functions) والخاصّيّات (properties) وتستمر بتتبُّعها (مثل معرفة اسم أو نوع الخاصّيّة والدالة أثناء التنفيذ) وهذا يرتبط ارتباطًا وثيقًا مع استخدام النمط الوظائفيّ (functional) أو التفاعليّ (reactive). ملاحظة: إن الجزء التنفيذيّ (runtime component) المطلوب في منصّة العمل Java لاستخدام ميزات الانعكاس يُوزَّع كملف ‎.jar مستقلٍّ (kotlin-reflect.jar) وذلك بهدف تخفيض حجم التخزين المطلوب لمكتبة التنفيذ (runtime library) للتطبيقات غير ...

إنشاء الواجهات ملاحظة: هل تبحث عن مزيد من المعلومات حول كيفية كتابة قوالب Blade؟ ألق نظرة على توثيق Blade الكامل للبدء. تحتوي الواجهات على HTML الذي يُقدّمه تطبيقك وتفصل منطق وحدة التحكّم/منطق التطبيق من منطق عرضك التقديمي (presentation logic). تُخزّن الواجهات في المُجلّد resources/views. قد تشبه الواجهة البسيطة المثال التالي: <! - الواجهات مُخزّنة في resources/views/greeting.blade.php -> <html> <body> <h1>Hello, {{ $name }}</h1> </body> </html> كما ترى، يُوافق المّتغيّر الوسيط ...

المشكلة الحاجة إلى استبدال خوارزميّة ما بخوارزميّة أخرى. الحل تعديل محتوى التابع (method body) الذي يُنفِّذ الخوارزمية السابقة ليُنفِّذ الخوارزمية الجديدة. مثال قبل إعادة التصميم تتلخَّص مهمة التابع foundPerson بالبحث عن الأشخاص ذوي الأسماء "Don" أو "John" أو "Kent" وذلك بالمرور بعناصر المصفوفة النصّيّة people باستخدام حلقة for كما في الشيفرة: في لغة Java: String foundPerson(String[] people){ for (int i = 0; i < people.length; i++) { if (people[i].equals("Don")){ return "Don"; ...

يستدعي المعامل === كتلة التابع مع تمرير الكائن الواقع على يمينه كوسيط إلى المعامل الواقع على يساره كما هو الحال في Proc.call. هذا يَسمح لكائنٍ من النوع proc أن يكون هدفًا للكتلة when في التعليمة case. البنية العامة proc === obj→ result_of_proc‎ القيمة المعادة تعاد نتيجة الوسيط proc. انظر أيضا التابع ==: يتحقق من تساوي كائنين من النوع Method. مصادر قسم التابع ===‎ في الصنف Method‎ في توثيق روبي الرسمي.

يستدعي معامل الفهرسة [] الكتلة البرمجية للتابع، ويضبط قيم معاملات الكتلة عند القيم المعطاة ضمنه باستخدام صياغة مشابهة لاستدعاء التوابع ثم يعيد قيمة آخر تعبير تم تقييمه في الكتلة. لاحظ أنَّ ‎prc.()‎ يستدعي prc.call()‎ مع تمرير الوسائط المعطاة. وهي صياغة مختصرة لإخفاء التابع "call". بالنسبة للكائنات procs التي تم إنشاؤها باستخدام lambda أو ‎->()‎‎‎، سيُطلق خطأ إذا كان عدد المعاملات الممررة إلى proc غير صحيح. بالنسبة للكائنات proc التي تم إنشاؤها باستخدام Proc.new أو Kernel.proc، سيتم تجاهل المعاملات الإضافية بصمت، ...

يتحقق المعامل == من تساوي كائنين من النوع Method. يكون كائنان من النوع Method متساويين إن كانا مرتبطين بنفس الكائن، وكانا لهما نفس التعريف، وكان لهما نفس الصنف أو الوحدة (module) المالكة. البنية العامة meth == other_meth → true or false‎ القيمة المعادة تُعاد القيمة true إن كان الكائنان متساويين، وإلا فستُعاد القيمة false. انظر أيضا التابع ===: يستدعي كتلة التابع مع تمرير الكائن الواقع على يمينه كوسيط إلى المعامل الواقع على يساره كما هو الحال في Proc.call. مصادر قسم ...

المشكلة وجود تعبيرٍ (expression) معقِّد يصعُب فهمه. الحل وضع ناتج التعبير أو جزءٍ منه في متغيِّرات (variables) واضحةٍ تُسهِّل الفهم. مثال قبل إعادة التصميم نلاحظ وجود تعبيرٍ شرطيٍّ (conditional expression) معقَّدٍ وبعدّة أجزاء كما في الشيفرة الآتية: في لغة Java: void renderBanner() { if ((platform.toUpperCase().indexOf("MAC") > -1) && (browser.toUpperCase().indexOf("IE") > -1) && wasInitialized() && resize > 0 ) { // افعل شيئًا ...

توصيف المشكلة التطابق بالمهام (function) ما بين صنفين (classes) ولكن بأسماءٍ مختلفةٍ لتوابعهما (methods). أسبابها عدم دراية المبرمج بوجود صنفٍ آخر يكافِئ بمهامّه مهامّ الصنف الحالي الذي ينشِئه. وما الحل؟ حذف أحد الصنفين بعد تنفيذ إحدى الحلول الآتية: إعادة تسمية التوابع (methods) لتصبح متطابقةً بكافّة الأصناف البديلة (alternative) (أي الأصناف المتكافئة بالمهام). توحيد التوقيع (signature) وتعريف الاستخدام ما بين التوابع، وذلك إمّا بنقل التابع (move method) أو إضافة المعاملات (add parameters) أو دمج التوابع عبر المعاملات (parameterize method). إن كان ...

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

توصيف المشكلة وجود العديد من أصناف البيانات في الشيفرة، والتي تُستخدَم لتخزين البيانات التي تحتاج إليها الأصناف الأخرى، إذ تحتوي على حقولٍ للبيانات (fields) وتوابع للوصول إليها (accessors) أي توابعَ للحصول على بيانات الحقول (getter) وأخرى لتعديلها (setter)، ولا تقوم هذه الأصناف بأيّ مهمّة أخرى ولا تستطيع كذلك تنفيذ العمليات (operations) على بياناتها بمفردها. أسبابها من الطبيعي أن يحتوي الصنف -بادئ الأمر- على القليل من الحقول العامّة (public fields) وبعض التوابع للوصول إليها (accessors) ولكن إن استمرَّ الصنف كذلك فلن ...

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

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

يستدعي call كتلة التابع الذي استٌدعي معه، ويضبط وسائط الكتلة عند القيم المُمرَّرة إليه باستخدام صياغة مشابهة لصياغة استدعاء التوابع ثم يعيد قيمة آخر تعبير تم تقييمه في الكتلة. لاحظ أن ‎prc.()‎ يستدعي prc.call()‎ مع تمرير المعاملات المعطاة. وهي صياغة مختصرة لإخفاء التابع "call". بالنسبة للكائنات procs التي تم إنشاؤها باستخدام lambda أو ‎->()‎‎‎، سيُطلق خطأ إذا كان عدد المعاملات الممررة إلى proc غير صحيح. بالنسبة للكائنات proc التي تم إنشاؤها باستخدام Proc.new أو Kernel.proc ، سيتم تجاهل المعاملات الإضافية ...

توصيف المشكلة وجود العديد من الاستدعاءات المتسلسلة في الشيفرة، مثل: ‎$a->b()->c()->d()‎. أسبابها تحدث المشكلة عند طلب العميل (client request) كائنًا (object) آخر والذي بدوره يطلب كائنًا آخر ثالثًا وهكذا، مما يعني اعتماد العميل على التنقّل (navigation) في بنية الأصناف (class structure)، وبالتالي فإنّ أيّ تعديلٍ في تلك العلاقات سيتطلَّبُ إجراء التعديلات أيضًا على العميل بحدِّ ذاته. وما الحل؟ إخفاء التفويض (hide delegate) لحذف الاستدعاءات المُتسلسلة. قد يساعد -ببعض الحالات- التفكيرُ بسبب الوصول إلى آخر كائنٍ (object) مستدعى، وعندها يمكن اللجوء ...

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

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

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

الدالة String.prototype.normalize()‎ تُعيد صيغة Unicode Normalization Form للسلسلة النصية المعطاة. البنية العامة str.normalize([form]) form إحدى القيم "NFC" أو "NFD" أو "NFKC" أو "NFKD"، التي تُحدِّد صيغة Unicode Normalization Form، وإذا لم تُحدَّد أو كانت undefined فستُستخدَم القيمة "NFC": NFC‏ — Normalization Form Canonical Composition. NFD ‏— Normalization Form Canonical Decomposition. NFKC ‏— Normalization Form Compatibility Composition. NFKD ‏— Normalization Form Compatibility Decomposition. القيمة المعادة سلسلة نصية تحتوي على صيغة Unicode Normalization Form من السلسلة النصية المعطاة. الاستثناءات سيُرمى الاستثناء RangeError ...

توصيف المشكلة استخدام أحد الأصناف (class) الحقولَ (fields) والتوابعَ (methods) الداخليّة لصنفٍ آخر بكثرة. أسبابها تعاملُ الأصناف (classes) مع بعضها بكثرةٍ، وهذا ما يجب أن تكون على درايةٍ به، إذ إنّ التصميم الجيّد يشترط الحدَّ من التواصل فيما بينها ما أمكن، وهذا سيسهِّل صيانتها (maintenace) وإعادة استخدامها (reuse). وما الحل؟ نقلُ التوابع (move methods) ونقل الحقول (move fields) من الصنف الحاليّ إلى الصنف الآخر الذي تُستخدَم فيه، وهو الحلُّ الأبسط عندما لا يحتاج الصنف الأول تلك الحقول والتوابع المنقولة. استخراج ...

توصيف المشكلة تحتوي الحقول المؤقَّتة على قيمٍ (وتُستخدَم وفقًا لها في الكائنات [objects]) ضمن شروطٍ مُحدَّدة، وتبقى فارغةً عند عدم تحقٌّق تلك الشروط. أسبابها تُخصَّصُ الحقول المؤقتة لاستخدامها في الخوارزميات التي تتطلَّب عددًا كبيرًا من المُدخلات (inputs)، فبدلًا من إنشاء الكثير من المعاملات في التابع (method parameters) يلجأ المُبرمِج لإنشاء حقولٍ مؤقَّتة لاحتواء البيانات المطلوبة في الصنف (class)، وبهذا فإنّ استخدام تلك الحقول لا يتعدّى تنفيذَ الخوارزميّة المُحدَّدة (ولا وظيفة أخرى لها خارج ذلك النطاق)، ويجعل وجودُ تلك الحقول من ...

يبذل المبرمج عادةً ما بوسعه لكتابة شيفرةٍ جيدةٍ، ولا ينوي أبدًا -أيًّا كان المبرمج- الحصولَ على شيفرةٍ رديئةٍ تكون السبب في فشل مشروعه البرمجيّ، لذا فلنطرح السؤال: ما هو الحدُّ الذي تصبح عنده الشيفرةُ النظيفةُ رديئةً؟ فخ الأعباء التقنية اقتُرح مصطلح "الأعباء أو الالتزامات التقنيّة" (ويقابله بالانكليزيّة Technical Debt) للمرّة الأولى من قِبل Ward Cunningham، فإنه لدى اقتراضك مبلغًا ماليًا من أحد المصارف تكبُر أمامك فرصة الشراء بشكلٍ أسرع، ويحدث أن تدفعَ علاوةً (وأيّ إضافات أخرى) لتسريع الأمر والحصول على ...

توصيف المشكلة وجود ما يزيد عن ثلاثة أو أربعة معاملات (parameters) مُمرَّرة للتابع (method). أسبابها قد تحدث هذه المشكلة عند دمج عدّة خوارزمياتٍ بنفس التابع (method)، إذ تُستخدَم المعاملات (parameters) الكثيرة لتحديد الخوارزمية التي ستُنفَّذ وآليّتها. أو قد تنتج المشكلة عن محاولة المبرمج أو المطوِّر لجعل الأصناف (classes) أكثر استقلاليةً عن بعضها البعض. فمثلًا: عند نقل الشيفرة التي تنشِئ الكائنات (objects) -اللازمة لأحد التوابع- من داخل التابع إلى الشيفرة التي تستدعي ذلك التابع سيتطلَّبُ تمرير تلك الكائنات إلى التابع كمعاملاتٍ ...

توصيف المشكلة وجود أصنافٍ (classes) أو توابعَ (methods) أو حقولٍ (fields) أو معاملاتٍ (parameters) غير مُستخدَمة في الشيفرة. أسبابها إنشاء عناصرَ إضافيّةٍ "قد" يحتاجها المبرمج مستقبلًا لميّزات يُخطِّط لها (وقد لا تُنفَّذ أصلًا)، وغير مستخدمةٍ بالوقت الحاليّ، مما يجعل الشيفرة أكثر صعوبةً بالفهم والدعم. وما الحل؟ هدم الهيكليّة الهرميّة (collapse hierarchy) لإزالة الأصناف المُجرَّدة (abstract classes) غير المُستخدَمة. دمج الأصناف (inline classes) للحدُّ من عمليات تفويض المهامّ (delegation) غير الضروريّة لصنفٍ آخر. دمج التوابع (inline methods) للتخلُّص من التوابع عديمة ...

وهي الأجزاء عديمة النفع في الشيفرة، وسيجعلُ التخلُّصُ منها الشيفرةَ نظيفةً يسيرة الفهم وأكثر فعاليّة، منها: التعليقات (comments) المشكلة: وجود الكثير من التعليقات في التوابع (methods) بهدف الشرح التفصيليّ للشيفرة. الحل: يكون الحل بناءً على الحالة المستعملة وهو: تقسيم التعبير الواحد إلى تعابيرَ فرعيّة (subexpressions) بالاعتماد على استخراج المتغيِّرات، أو عزل ذلك المقطع في تابعٍ (method) جديدٍ باسمٍ معبِّر، أو إعادة تسمية التابع (rename method) لاسمٍ يشرح ذاته بذاته، أو إضافة التأكيدات. تكرار  الشيفرة (duplicates) المشكلة: التشابه (أو التطابق المطلق) بين مقطعين من الشيفرة ...

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

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

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

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

المشكلة الحاجة إلى بعض التوابع (methods) غير الموجودة في الصنف المساعد (utility class)، ومن غير الممكن إضافتها إلى ذلك الصنف. الحل إنشاء صنفٍ (class) جديدٍ يحتوي التوابع اللازمة، وجعله كصنف تغليفٍ (wrapper) للصنف المساعد أو كصنفٍ فرعيٍّ (subclass) له. مثال قبل إعادة التصميم يعتمد صنف العميل ClientClass على الصنف المساعد Date ولكنّه بحاجة إلى بعض التوابع غير الموجودة فيه (كتابع الحصول على اليوم التالي مثلًا): الصنف العميل ClientClass الذي يعتمد على الصنف المساعد Date. بعد إعادة التصميم أصبح هنالك صنف ...

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

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

المشكلة يصل العميل (client) إلى كائنٍ (object) ما وليكن الكائن B من أحد حقول (fields) أو توابع (methods) كائنٍ آخر وليكن A، ومن ثمّ يستدعي تابعًا لهذا الكائن B. الحل إنشاء تابعٍ جديدٍ في الصنف A والذي يُفضي إلى استدعاءٍ للكائن B، وبهذا لن يعلم العميل تفاصيل التفويض (delegation) للكائن B ولن يعتمد على ذلك. مثال قبل إعادة التصميم يتعامل صنف العميل (client class) مع صنفين، الأول صنف الأقسام (Department) والثاني صنف الأشخاص (Person) واللذان يحتويان تابعين للحصول على كائنٍ ...

مقدمة Valet هي بيئة تطوير Laravel لأجهزة ماك. لا حاجة إلى استخدام Vagrant، ولا ملف ‎/etc/hosts. يمكنك أيضًا مشاركة مواقعك بشكل عام باستخدام الأنفاق المحلية. تقوم بيئة Laravel Valet بتكوين جهاز ماك الخاص بك لتشغيل Nginx دائمًا في الخلفية عند بدء تشغيل الجهاز. ثم، باستخدام DnsMasq، يقوم خادم Valet بتجميع جميع الطلبات على نطاق test.* للإشارة إلى المواقع المثبتة على جهازك المحلي. بعبارة أخرى، بيئة تطوير Laravel فائق السرعة تستخدم ما يقرب من 7 ميغابايت من ذاكرة الوصول العشوائي RAM. ...

يملك التجريد (Abstraction) تقنيات إعادة التصميم الخاصة به والمرتبطة بشكل أساسي بوظيفة النقل على طول التسلسل الهرمي لوراثة الصنف (class inheritance hierarchy)، وبإنشاء أصناف وواجهات جديدة، وبتبديل التفويض مكان الوراثة أو العكس. تقنيات هذا القسم هي: استخراج الأصناف الفرعية (Extract Subclass) المشكلة: يكون للصنف ميزات تستعمل فقط في حالات معينة. الحل: إنشاء صنف فرعي واستخدامه في هذه الحالات. استخراج الأصناف الفائقة (Extract Superclass) المشكلة: وجود صنفين لهما حقول وتوابع مشتركة. الحل: إنشاء صنف أب مشترك لهما ونقل جميع الحقول والتوابع ...

توصيف المشكلة لا تلبِّي أصناف المكتبة (library classes) كافّة احتياجات البرنامج مع استمرار تطوُّره، ولا يمكن تعديلها لأنّها مُخصَّصةٌ للقراءة فقط (read-only). أسبابها عدم تزويد مُطوِّر المكتبة كافَّةَ الميّزات (features) التي تحتاجها في البرنامج أو امتناعه عن تعريفَ استخدامها (implement). وما الحل؟ لتعريف بعض التوابع (methods) في المكتبة عليك بتعريف التوابع الدخيلة (introduce foreign methods). أمّا لإجراء تغييراتٍ واسعةٍ في صنف المكتبة فعليك بتعريف الإضافات المحليّة (introduce local extensions). إليك المزيد سيكون حلُّ المشكلة كفيلًا بالتقليل من تكرار الشيفرات (duplications)، ...

توصيف المشكلة استفادة الصنف الفرعيّ (subclass) من القليل فقط ممّا ورِثه عن الصنف الأعلى (superclass) من توابعَ (method) وحقولٍ (fields)، لتبقى التوابع الأخرى غيرَ مُستخدَمةٍ أو قد يُعاد تعريفها (redefined) مع الكثير من الاختلافات. أسبابها إنشاء علاقة الوراثة (inheritance) ما بين صنفين مختلفين كليًّا بدافع إعادة استخدام الشيفرة الموجودة في الصنف الأعلى (superclass) في الصنف الفرعيّ (subclass). وما الحل؟ إن لم يشترك الصنف الفرعيّ (subclass) مع الصنف الأعلى (superclass) بشيءٍ، فالوراثة غير منطقيّةٍ بالأصل، والأفضلُ التخلي عنها بتبديلها إلى تفويض ...

توصيف المشكلة تكرار مجموعةٍ من المتغيِّرات (variables) (كتلك المُستخدَمة كمعاملاتٍ [parameters] للربط مع قاعدة البيانات مثلًا) بشكلٍ متطابقٍ تمامًا في عدّة أجزاء من الشيفرة، إذ يجب تحويل تلك المجموعات إلى أصنافها (classes) الخاصّة بها. أسبابها تُعزى المشكلة عمومًا للبُنية (structure) البرمجيّة الضعيفة (أو ما يُعرف بمصطلح copypasta programming)، وللتحقُّقِ من وجود هذه المشكلة بالشيفرة احذف إحدى القيم، فإنْ حدث خللٌ نتيجة الحذف فالمشكلة قائمة ويجب علاجها، وإلّا فتلك إشارةٌ حسنةٌ ومن المحبَّذ تجميعُ هذه المتغيِّرات في كائنٍ واحدٍ. وما الحل؟ ...

المشكلة لا يُستخدم معاملٌ ما في متن التابع. الحل إزالة المعامل غير المستخدم. مثال قبل إعادة التصميم تعريف المعامل Date في بداية التابع ()getContact وعدم استخدامه. تعريف المعامل Date في بداية التابع ()getContact وعدم استخدامه. بعد إعادة التصميم إزالة المعامل Date من التابع ()getContact لعدم استخدامه: إزالة المعامل Date من التابع ()getContact. لم إعادة التصميم؟ يفرض كل معامل موجود في استدعاء التوابع على المبرمج أن يقرأه لمعرفة ما هي المعلومات الموجودة في هذا المعامل. وإذا كان المعامل غير مستخدم على ...

المشكلة وجود صنفٍ (class) لا يقوم بأيّ مهمّة فعليّة ولا يُخطَّط لإضافة مهامٍ إليه لاحقًا. الحل نقل كافّة الميّزات (features) من هذا الصنف إلى صنفٍ آخر. مثال قبل إعادة التصميم يحتوي الصنف Person على حقلٍ واحدٍ باسم name وتابعٍٍ للحصول على رقم الهاتف getTelephoneNumber ولاشيء آخر، أمّا الصنف TelephoneNumber فهو يحتوي على حقلين باسم officeAreaCode و officeNumber بالإضافة إلى التابع السابق getTelephoneNumber، كما هو موضَّحٌ في مخطط الأصناف الآتي: الصنف Person يحتوي على حقلٍ واحدٍ باسم name وتابعٍٍ للحصول على ...