لقد حدث أن كنت في السنوات القليلة الماضية أمارس الخياطة مع فرانكشتاين ، وليس نحت تماثيل خزفية لطيفة من الرعاة واجتياح المداخن. أقوم بإنشاء حلول تستند إلى Magento 2. وهذا يعني أن المادة المصدر هي حلم أي عالم آثار. الطبقة الثقافية مع آثار مختلف "العصور" و "الحضارات". يمكن استخدامه لدراسة تطور الفكر المبرمج في مجتمعات PHP / JS خلال العقد الماضي.

وهذا هو الأساس فقط ، والوظيفة الإضافية هي الوحدات التابعة لجهات خارجية والتي يجب دمجها في الداخل. هنا من الممكن بالفعل مواجهة مظاهر الذكاء خارج كوكب الأرض. يتم إنشاء بعض الوحدات بواسطة كائنات متطورة ، تشبه إلى حد كبير التفكير في المبدعين الأساسيين ، لكنك تصادف تلك التي تريد أن تأخذ المؤلف بها من الكتف ، وتنظر بعمق في عينيه وتسأل بطريقة ودية: "من أي كوكب أنت ، موطني؟ "

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

التعتيم وتشفير الكود

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

رابعا كود سطر واحد

الحفظ على سطور الكود هو الأكثر ضررًا في قائمتي:

if ($cond) aaa(); else bbb(); 

توقف خطوتين على هذا الخط أثناء تنفيذ البرنامج خطوة بخطوة (حساب الشرط ، وتنفيذ الفرع true أو false ). كل شيء على مايرام ، كل ما تحتاجه هو أن تضع في اعتبارك عدد المرات التي قمت فيها بتنفيذ خطوة على هذا الخط ، وتتبع قيمة $cond في قائمة المتغيرات. مع مرور الوقت ، تطورت الأتمتة.

الأسوأ قليلاً هو أنه لا يمكنك تعيين نقطة توقف غير مشروطة على الفرع true أو false . بدلاً من نقرة واحدة في IDE ، سيكون عليك العمل مع الماوس / لوحة المفاتيح لفترة أطول قليلاً ، مع إضافة نقطة توقف مشروطة.

الخيار المثالي هو عندما تكون كل خطوة قابلة للتنفيذ (الشرط ، والإضاءة true ، والإضاءة false ) على خطها الخاص:

 if ($cond) aaa(); else bbb(); 

ثالثا. نتيجة التعبير

استخدام التعبيرات في الشروط:

 if (exp()) ... 

دورات:

 foreach (exp() as $item) ... 

كمعلمات:

 foo(exp(), ...) 

وإرجاع النتيجة:

 return exp(); 

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

الخيار المثالي هو متغير مؤقت:

 $exp = exp(); if ($exp) ... 

الثاني. العديد من نقاط الخروج

مرات عديدة صادفت التوصية للحصول على نقطة خروج واحدة فقط من الوظيفة ومرات عديدة صادفت انتهاكًا لهذه التوصية (مثال تم اختراعه ، ولكنه مثال نموذجي):

 public function onEvent($event) { if($event == 'entrance') { return 'entranceRoute'; } else if($event == 'exit') { return 'exitRoute'; } return 'defaultRoute'; } 

إليك خيار أكثر صحة:

 public function onEvent($event) { $result = 'defaultRoute'; if($event == 'entrance') { $result = 'entranceRoute'; } else if($event == 'exit') { $result = 'exitRoute'; } return $result; } 

هذا كل شيء ، لست بحاجة إلى تفريق نقاط التوقف عند كل return أو القيام بخطوة من السطر الأول (إذا أعطاني رمز الاتصال الفرصة لرؤية النتيجة في متغير منفصل) لفهم كيف انتهى التنفيذ. تخيل وظيفة مع 120 خطوط و 22 عائدات في الداخل؟ لقد تخلت عن هذا الأمر بنفسي وأظن أن هذا ليس الحد الأقصى.

I. تعاقب أسلوب المكالمات

المفضل لدي هو الأسلوب المتتالي :

 $collection ->addFilterByProduct(...) ->addShowInStoresFilter(...) ->addPublicFilter(...) ->addApprovedStatusFilter(...) ->addCreatedAtLessThanNowFilter(...); 

إذا كنت بحاجة للدخول إلى طريقة addApprovedStatusFilter() ، والتي هي واجهة ويتم تنفيذها في عدة فئات مختلفة (يتم تحديد فئة محددة في وقت التشغيل) ، فإن أبسط شيء هو تعيين نقطة توقف على $collection addFilterByProduct كل شيء بدوره ( addFilterByProduct ، addShowInStoresFilter ، addPublicFilter ) يصل إلى المكان الصحيح. إذا قمت بضم هذا باستخدام التعبيرات في المعلمات والنتائج التي تم إرجاعها ، يصبح المسار غير قريب تمامًا. في الأصل ، يبدو هذا الرمز كما يلي:

 $collection ->addFilterByProduct($this->getProduct()) ->addShowInStoresFilter($this->_storeManager->getStore()->getId()) ->addPublicFilter() ->addApprovedStatusFilter() ->addCreatedAtLessThanNowFilter(); 

نعم ، مع أساليب التعاقب ، تصبح الشفرة أكثر قابلية للقراءة ، لكن الخصم يصبح أكثر صعوبة. ليس لدي أي شيء ضد مجموعة set'er (أنا ، كقاعدة عامة ، لا أضع المستوطنين لأول مرة):

 $answerModel ->setAuthorName(...) ->setStatus(...) ->setCreatedAt(...) ->setAuthorEmail(...) ->setCustomerId(...) ->setHelpfulness(...) 

لكن الكود الذي يحتوي على المنطق الذي قد يلزم خصمه ، أو ربما بنفسي ، من الأفضل أن يكتب " المدرسة القديمة " (أفعل ذلك بنفسي):

 $collection->addFilterByProduct(...); $collection->addShowInStoresFilter(...); $collection->addPublicFilter(...); $collection->addApprovedStatusFilter(...); $collection->addCreatedAtLessThanNowFilter(...); 

هل أصبح إدراكه أكثر صعوبة؟

أو فيما يلي التوصيات الخاصة بنمط البرمجة الجيد:

 ladder.up().up().down().up().down().showStep(); 

انظر إلى هذا من وجهة نظر أحد المُوَجِّع ، الذي يجب أن يدخل داخل الثانية down .

ملخص

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

تنصل

ما سبق هو نتيجة للتشوه المهني الشخصي وقد يختلف عن الآراء بناءً على التشوهات المهنية الأخرى.