Buggy Cake كود PHP: الأخطاء الستة الأكثر شيوعًا التي يرتكبها مطورو PHP

CakePHP عبارة عن إطار عمل PHP مذهل ، ولكنه يحتوي على منحنى تعليمي حاد! يتطلب الأمر قدرًا كبيرًا من البحث والتدريب لتصبح خبيرًا.

لقد كنت محظوظًا باستخدام CakePHP لأكثر من 7 سنوات حتى الآن ، وفي ذلك الوقت كان لي شرف العمل مع العديد من أعضاء مجتمع CakePHP.

في هذا البرنامج التعليمي CakePHP أود أن أصف بعض الممارسات السيئة التي رأيتها على مر السنين ، واقترح النهج الصحيح لتجنب هذه الأخطاء. هذا لا يعني أن الكود الخاص بي مثالي ، ولكن بصفتي مبرمجًا ، نتعلم دائمًا ، لذلك من المهم اتباع أفضل الممارسات والتكيف مع التعلم!

محتوى هذه المقالة مستوحى من منشور من CakeCoded. إذا كنت ترغب في معرفة المزيد عن CakePHP ، يرجى زيارة قسم التعلم هنا.

الخطأ الشائع رقم 1: عدم اتباع اصطلاحات تشفير CakePHP

يمكن الاطلاع على اصطلاحات ترميز CakePHP هنا. سأقوم بتسليط الضوء على بعض الأشياء التي غالبًا ما ألاحظها عند عرض كود المبرمجين الآخرين.

جمل التحكم. غالبًا ما ترى المبرمجين يخطئون ، وفي بعض الحالات يجلبون ممارسات من لغات برمجة أخرى. يتوقع CakePHP الصيغة التالية:

 if ((expr_1) || (expr_2)) { // action_1; } elseif (!(expr_3) && (expr_4)) { // action_2; } else { // default_action; }

يجب أن يكون هناك مسافة 1 (واحد) قبل القوس الأول ومسافة 1 (واحد) بين القوس الأخير وقوس الفتح. وهذا يعني أن ما يلي غير صحيح:

 if($this->request->data){ }

لاحظ التباعد بين if و ( ، وبين ) و {

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

لذلك ، على سبيل المثال ، ما يلي غير صحيح:

 if ($foo) $bar = true

يجب أن يتم تنسيق هذا على النحو التالي:

 if ($foo) { $bar = true }

أخيرًا ، شاهد المكان الذي تضع فيه الأقواس. يجب ألا تبدأ أقواس الفتح سطرًا جديدًا. وتأكد من محاذاة جميع الأقواس بحيث يكون كل قوس جديد في خط مع قوس الإغلاق.

فيما يلي بعض الأمثلة غير الصحيحة:

 if ($foo) { $bar = true; }

هذا غير صحيح ، يجب أن يكون قوس الفتح في السطر الأول:

 if ($foo) { $bar = true; if ($action) { $to = false; } }

المسافة البادئة تحتاج إلى الاصطفاف بشكل صحيح.

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

الخطأ الشائع رقم 2: الاستخدام غير السليم للسلوكيات القابلة للاحتواء والمستويات التكرارية في ORM

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

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

أبحث عن شيئين عند تدقيق موقع ويب موجود. أولاً ، هل تم تغيير المستوى التكراري الافتراضي؟ بشكل افتراضي ، يضبط CakePHP المستوى العودي على 1 ، وهو في رأيي مرتفع جدًا. أقوم دائمًا بتعيينه على -1 ثم استخدم السلوك القابل للاحتواء للحصول على أي نماذج ذات صلة.

هذا يقودني إلى الشيء الثاني الذي أبحث عنه - هل تم استخدام سلوك الاحتواء؟ غالبًا ما يأتي إلي عملاء جدد ويقولون إن CakePHP بطيئة. السبب دائمًا تقريبًا هو أنه لم يتم استخدام الاحتواء! سوف يقوم مبرمج CakePHP الجيد بتحسين استعلامات SQL الخاصة بهم بغض النظر عن مقدار "السحر التلقائي" الذي يتم وراء الكواليس.

لم تتم إضافة سلوك الاحتواء حتى CakePHP 1.2 ، لكن هل أحدث هذا فرقًا ؟! تأكد من استخدام المحتوى القابل للاحتواء قدر الإمكان ، لأنه طريقة فعالة لتحسين SQL الخاص بك. لمزيد من المعلومات حول كيفية تنفيذ واستخدام سلوك الاحتواء ، انقر هنا.

الخطأ الشائع الثالث: الحفاظ على منطق الأعمال في وحدات التحكم بدلاً من النماذج

كود CakePHP الجيد سيكون له المنطق في ملفات النموذج. يستغرق هذا الأمر بعض الوقت لتعتاد عليه ، ولكن بمجرد إتقانه لن يكون هناك عودة إلى الوراء! يجب استخدام ملف وحدة التحكم لما هو مخصص له في نمط MVC - التحكم! لذا استخدم ملف وحدة التحكم الخاص بك للتعامل مع إجراءات المستخدم ، مع ترك منطق الأعمال في ملف النموذج.

وخير مثال على ذلك هو عمل بسيط - عمل يومي! لنأخذ وظيفة إضافة منشورات من برنامج تعليمي للمدونة كمثال. وظيفة الإضافة الافتراضية هي كما يلي:

 public function add() { if ($this->request->is('post')) { $this->Post->create(); if ($this->Post->save($this->request->data)) { $this->Session->setFlash(__('Your post has been saved.')); return $this->redirect(array('action' => 'index')); } $this->Session->setFlash(__('Unable to add your post.')); } }

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

بدلاً من ذلك ، نكتب دالة لهذا في نموذج Post.php الخاص بنا. ربما شيء من هذا القبيل:

 public function addPost($data = array(), $emailAdmin = true) { $this->create(); $this->save($data); // update any other tables // send the email to the admin user if ($emailAdmin) { } // if all is successful return true; }

سيؤدي ذلك بعد ذلك إلى تغيير بسيط في إجراء وحدة التحكم على النحو التالي:

 public function add() { if ($this->request->is('post')) { if ($this->Post->addPost($this->request->data)) { $this->Session->setFlash(__('Your post has been saved.')); return $this->redirect(array('action' => 'index')); } $this->Session->setFlash(__('Unable to add your post.')); } }

كما ترى ، فإن الإجراء الجديد هو في الواقع سطر واحد أقل ، لأن $this->Post->create() قد تم نقله إلى ملف النموذج.

هذا مثال يومي مثالي على المكان الذي يكون فيه نقل المنطق إلى ملف النموذج فكرة جيدة - وهو بالتأكيد يجعل قاعدة رمز أكثر وضوحًا!

الخطأ الشائع الرابع: إضافة الكثير من التعقيد إلى التعليمات البرمجية ، بدلاً من العودة في كثير من الأحيان وفي وقت مبكر

هذا دائمًا نقاش مستمر ، لكن العودة كثيرًا ، والعودة مبكرًا بالتأكيد تجعل الكود أكثر نظافة. هذا ينطبق على أساليب النموذج أكثر من أي شيء آخر.

لكن ماذا أعني بالضبط؟ حسنًا ، لنلقِ نظرة على الطريقة التي أضفناها في البرنامج التعليمي CakePHP أعلاه:

 public function addPost($data = array(), $emailAdmin = true) { $this->create(); $this->save($data); // update any other tables // send the email to the admin user if ($emailAdmin) { } // if all is successful return true; }

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

قد يكون من الأسهل إظهار هذا بمثال. هناك طريقتان يمكن كتابة الوظيفة أعلاه:

 public function addPost($data = array(), $emailAdmin = true) { if ($data) { $this->create(); $result = $this->save($data); if ($result) { // update any other tables // send the email to the admin user if ($emailAdmin) { // send the admin email } } else { // problem saving the data return false; } // if all is successful return true; } else { // no data submitted return false; } }

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

 public function addPost($data = array(), $emailAdmin = true) { if (!$data) { // no data submitted return false; } $this->create(); $result = $this->save($data); if (!$result) { // problem saving the data return false; } // update any other tables // send the email to the admin user if ($emailAdmin) { // send the admin email } // if all is successful return true; }

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

هذا يسمح لمبرمج CakePHP بالكتابة بنفس الطريقة التي نقرأ بها - قراءة الكود من اليسار إلى اليمين ، من أعلى إلى أسفل ، بدلاً من الكتل المختلفة ، والتي يمكن أن تصبح مربكة بسرعة!

الخطأ الشائع الخامس: عدم استخدام مبدأ الجفاف

DRY تعني لا تكرر نفسك ، وهي فلسفة يجب اتباعها عند الترميز في CakePHP. مع الكود الكينوني ، لا يوجد عذر لتكرار نفس كتلة الكود مرتين!

فيما يلي بعض نصائح CakePHP لضمان عدم تكرار كلامك:

• كما ذكرنا سابقًا ، حاول وضع منطق في ملفات النموذج حتى تتمكن من مشاركة المنطق.

• في ملفات العرض الخاصة بك ، إذا كنت تقوم بتكرار طرق العرض ، فقم بإنشاء كود العرض كعنصر ، أو حتى كمساعد مخصص.

• قم بإعداد بعض إعدادات التكوين - يعد ملف app/Config/bootstrap.php مكانًا رائعًا لذلك. يساعد هذا في التأكد من أنك لا تقوم بترميز أشياء مثل اسم التطبيق وعنوان البريد الإلكتروني الرئيسي. آخر شيء تريد القيام به هو تصفح مئات الملفات لمجرد أن العميل قد طلب تحديث عنوان بريد إلكتروني في أحد التطبيقات.

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

الخطأ الشائع السادس: عدم التعليق على المدونة

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

يجب أن تتعارض قوالب CakePHP Doc مع الهامش الأيسر للصفحة. إذن مثال بسيط باستخدام الرمز أعلاه.

 /** * Adds & saves a post as well as emails the admin to let them know the post has been added. * Also performs some saving to another table * * @param array $data The post data * @param bool $emailAdmin If set to true, will email the website admin * @return bool Returns true if successful */ public function addPost($data = array(), $emailAdmin = true) {

كما سترى ، لا يستغرق الأمر وقتًا طويلاً لكتابة كتلة doc ، لكنها تحدث فرقًا كبيرًا من حيث طول عمر الكود. في النهاية ، هذا يعني أن الكود يمكن أن يعيش بعدك كمطور.

وبالمثل مع التعليقات المضمنة. لا تخف من شرح ما يفعله الكود ولماذا! إنه يسهل كثيرًا على المدى الطويل فهم الكود الخاص بك ، خاصةً إذا كان مطور آخر يبحث عنه!

يتم إحتوائه

CakePHP عبارة عن إطار عمل شامل كامل الميزات. نظرًا لأنه يتبع العرف على التكوين ، فإن CakePHP أكثر صرامة من الأطر الأخرى المستندة إلى PHP ، بمعنى أن المستخدم "مجبر" على اتباع طريقة معينة لوضع الكود. قد يكون هذا مثيرًا للجدل ، ولكن في تجربتي يؤدي إلى قاعدة رمز تكون أكثر اتساقًا وقابلية للفهم - بدلاً من السماح للمطور "باختيار" كيفية كتابة الكود ، سيقوم فريق التطوير بكتابة تعليمات برمجية متسقة باتباع اصطلاحات Cake .

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