Code CakePHP bogué : les 6 erreurs les plus courantes commises par les développeurs de CakePHP

CakePHP est un framework PHP incroyable, mais il a une courbe d'apprentissage abrupte ! Il faut une bonne quantité de recherche et de formation pour devenir un expert.

J'ai eu la chance d'utiliser CakePHP depuis plus de 7 ans maintenant, et pendant cette période j'ai eu l'honneur de travailler avec de nombreux membres de la communauté CakePHP.

Dans ce tutoriel CakePHP, j'aimerais décrire quelques mauvaises pratiques que j'ai vues au fil des ans, et proposer la bonne approche pour éviter ces erreurs. Cela ne veut pas dire que mon code est parfait, mais en tant que programmeur, nous apprenons toujours, il est donc important de suivre les meilleures pratiques et de s'adapter au fur et à mesure que vous apprenez !

Le contenu de cet article est inspiré d'un article de CakeCoded. Si vous souhaitez en savoir plus sur CakePHP, veuillez visiter notre section d'apprentissage ici.

Erreur courante #1 : Ne pas suivre les conventions de codage de CakePHP

Les conventions de codage de CakePHP peuvent être consultées ici. Je soulignerai quelques points que je remarque souvent lorsque je regarde le code d'autres programmeurs.

Structures de contrôle. Très souvent, vous voyez des programmeurs se tromper et, dans certains cas, apporter des pratiques d'autres langages de codage. CakePHP attend la syntaxe suivante :

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

Il doit y avoir 1 (un) espace avant la première parenthèse et 1 (un) espace entre la dernière parenthèse et le crochet ouvrant. Cela signifie donc que ce qui suit est incorrect :

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

Notez l'espacement entre le if et ( , et entre ) et {

Utilisez toujours des accolades dans les structures de contrôle, même si elles ne sont pas nécessaires. Ils augmentent la lisibilité du code et vous donnent moins d'erreurs logiques.

Ainsi, par exemple, ce qui suit est incorrect :

 if ($foo) $bar = true

Cela devrait être formaté comme ceci:

 if ($foo) { $bar = true }

Enfin, regardez où vous placez les crochets. Les parenthèses ouvrantes ne doivent pas commencer une nouvelle ligne. Et assurez-vous que tous vos crochets sont alignés de sorte que chaque nouveau crochet soit aligné avec le crochet de fermeture.

Voici quelques exemples incorrects :

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

Ceci est incorrect, le crochet ouvrant doit être sur la première ligne :

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

L'indentation doit s'aligner correctement.

J'entends souvent les programmeurs dire : "Mais je suis trop occupé pour rendre le code propre...". Ma réponse est: "Faites-moi confiance, un code soigné résistera à l'épreuve du temps". Écrire du code CakePHP qui n'est pas lisible sera un cauchemar auquel vous devrez revenir si vous avez besoin de faire un changement dans quelques mois.

Erreur courante n° 2 : Utilisation inappropriée des comportements confinables et des niveaux récursifs dans l'ORM

J'ai eu la chance récemment d'avoir une discussion informelle avec un développeur de base de données de Facebook. Nous avons commencé à parler de CakePHP et il m'a dit : « Oh, ça utilise ORM, n'est-ce pas ? Cela peut faire peur. Je lui ai demandé ce qu'il voulait dire, et il a commenté qu'avec le mappage objet-relationnel (ORM), il est facile pour les requêtes SQL de devenir inutilement volumineuses.

Il a raison d'une certaine manière. Une partie de la magie de CakePHP réside dans son utilisation d'ORM et dans la manière dont il regroupe différentes relations entre les tables de base de données. Par défaut, CakePHP sélectionne automatiquement toutes les données associées 'Appartient à', 'Has One' et 'Has Many', et cela peut conduire à de très grandes requêtes SQL. Ces requêtes peuvent ne pas être un problème lorsque vous développez initialement une application, mais après six mois de collecte de données en direct, vous pouvez constater que l'application devient très lente et, dans certains cas, se bloque si les requêtes ne sont pas optimisées.

Je fais attention à deux choses lors de l'audit d'un site Web existant. Tout d'abord, le niveau récursif par défaut a-t-il été modifié ? Par défaut, CakePHP définit le niveau récursif à 1, ce qui à mon avis est trop élevé. Je le règle toujours sur -1, puis j'utilise le comportement contenu pour obtenir tous les modèles associés.

Cela mène à la deuxième chose que je recherche - le comportement Contenable a-t-il été utilisé ? J'ai souvent de nouveaux clients qui viennent me voir et me disent que CakePHP est lent. La raison en est presque toujours parce que Containable n'a pas été utilisé ! Un bon programmeur CakePHP optimisera ses requêtes SQL quelle que soit la quantité d'"auto-magie" effectuée dans les coulisses.

Le comportement contenu n'a pas été ajouté avant CakePHP 1.2, mais bon sang, cela a-t-il fait une différence ? ! Assurez-vous d'utiliser autant que possible le conteneur, car c'est un moyen efficace d'optimiser votre SQL. Pour plus d'informations sur l'implémentation et l'utilisation du comportement Contenable, cliquez ici.

Erreur courante n° 3 : conserver la logique métier dans les contrôleurs plutôt que dans les modèles

Un bon code CakePHP aura la logique dans les fichiers modèles. Cela prend un peu de temps pour s'y habituer, mais une fois maîtrisé, il n'y a pas de retour en arrière! Un fichier de contrôleur doit être utilisé pour ce à quoi il est destiné dans le modèle MVC - contrôler ! Utilisez donc votre fichier de contrôleur pour gérer les actions de l'utilisateur, tout en laissant la logique métier aller dans le fichier de modèle.

Un bon exemple serait un simple CRUD - une action de tous les jours ! Prenons l'exemple de la fonction d'ajout de messages d'un tutoriel de blog. La fonction d'ajout par défaut est la suivante :

 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.')); } }

Cette action du contrôleur convient pour un simple ajout, mais que se passerait-il si vous vouliez faire des choses comme envoyer un e-mail à l'administrateur lorsqu'un message a été ajouté, ou mettre à jour une autre association de modèle lorsqu'un message a été ajouté. Il s'agit d'une logique supplémentaire, mais cette logique ne doit pas entrer dans notre fichier de contrôleur.

Au lieu de cela, nous écrirons une fonction pour cela dans notre modèle Post.php . Peut-être quelque chose comme ça :

 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; }

Cela entraînerait alors une petite modification de l'action du contrôleur comme suit :

 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.')); } }

Comme vous pouvez le voir, la nouvelle action est en fait une ligne de moins, car le $this->Post->create() a été déplacé vers le fichier modèle.

C'est un exemple parfait et quotidien de l'endroit où déplacer la logique vers le fichier modèle est une bonne idée - et cela crée certainement une base de code beaucoup plus propre !

Erreur courante n° 4 : Ajouter trop de complexité au code, au lieu de revenir souvent et tôt

C'est toujours un peu un débat en cours, mais revenir souvent et revenir tôt rend certainement le code beaucoup plus propre. Cela s'applique aux méthodes de modèle plus qu'à toute autre chose.

Mais qu'est-ce que je veux dire exactement ? Eh bien, regardons la méthode que nous avons ajoutée dans le tutoriel CakePHP ci-dessus :

 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; }

Revenir souvent et revenir tôt signifie qu'au fur et à mesure que nous exécutons notre fonction, nous vérifions régulièrement que tout va bien. Si ce n'est pas le cas, alors nous renvoyons false, ou renvoyons une erreur CakePHP.

Il serait peut-être plus facile de le montrer avec un exemple. Il y a deux façons d'écrire la fonction ci-dessus :

 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; } }

Vous voyez comment le code devient rapidement illisible ? Il y a if s et else s partout, et la fonction devient rapidement une grande indentation. Ne vous méprenez pas, j'adore l'indentation propre, mais regardez à quoi ressemble la fonction si elle est souvent écrite avec le retour, principe de retour précoce.

 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; }

Tout de suite, dans ce petit exemple, vous pouvez voir que le code n'a qu'une seule indentation et est beaucoup plus lisible. La logique a en fait plus de sens - laissez la logique passer ligne par ligne, et s'il y a un problème en cours de route, renvoyez l'erreur et ne passez pas à la ligne suivante.

Cela permet à un programmeur CakePHP d'écrire de la même manière que nous le lisons - en lisant le code de gauche à droite, de haut en bas, plutôt que dans des blocs différents, ce qui peut rapidement devenir déroutant !

Erreur courante #5 : Ne pas utiliser le principe DRY

DRY signifie Don't Repeat Yourself, et c'est une philosophie qui doit être suivie lors du codage dans CakePHP. Avec le code orienté objet, il n'y a aucune excuse pour répéter deux fois le même bloc de code !

Voici quelques astuces CakePHP pour vous assurer de ne pas vous répéter :

• Comme mentionné ci-dessus, visez à mettre une logique dans les fichiers de modèle afin de pouvoir partager la logique.

• Dans vos fichiers de vue, si vous répétez des vues, créez le code de vue en tant qu'élément, ou même un assistant personnalisé.

• Configurez certains paramètres de configuration - le fichier app/Config/bootstrap.php est un excellent endroit pour cela. Cela permet de s'assurer que vous ne codez pas en dur des éléments tels que le nom de l'application et l'adresse e-mail principale. La dernière chose que vous voulez faire est de parcourir des centaines de fichiers simplement parce que le client a demandé de mettre à jour une adresse e-mail dans une application.

• Demandez-vous toujours : « Si je répète du code, y a-t-il une meilleure façon d'écrire ce code, et est-ce que je mets ce code au bon endroit ? Il y a de fortes chances que si vous avez besoin de répéter du code, il pourrait être mieux écrit.

Erreur courante #6 : Ne pas commenter le code

Le dernier point que je ferai concerne les commentaires. Tout d'abord, le blocage de doc. Un bloc doc est lorsque vous documentez une méthode ou une action. Il ne faut qu'une minute pour enregistrer un peu ce que fait une fonction, mais cela fait une telle différence en termes de lisibilité du code.

Les blocs CakePHP Doc doivent aller contre la marge gauche de la page. Donc, un exemple simple utilisant le code ci-dessus.

 /** * 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) {

Comme vous le verrez, écrire un bloc de documentation ne prend pas longtemps, mais cela fait une énorme différence en termes de longévité du code. En fin de compte, cela signifie que le code peut vivre après vous en tant que développeur.

De même avec les commentaires en ligne. N'ayez pas peur d'expliquer ce que fait votre code et pourquoi ! Cela rend beaucoup plus facile à long terme la compréhension de votre code, surtout si un autre développeur le regarde !

Emballer

CakePHP est un framework complet et complet. Étant donné qu'il suit la convention plutôt que la configuration, CakePHP est plus strict que les autres frameworks basés sur PHP, dans le sens où un utilisateur est "obligé" de suivre une certaine manière de disposer le code. Cela peut être controversé, mais d'après mon expérience, cela conduit à une base de code plus cohérente, lisible et compréhensible - plutôt que de laisser un développeur "choisir" comment le code doit être écrit, une équipe de développement écrira un code cohérent en suivant les conventions de Cake .

En suivant ce tutoriel CakePHP et en vous assurant que votre code est bien écrit, les applications peuvent résister à l'épreuve du temps. Le code doit toujours être écrit pour demain - de sorte que si un autre développeur examine un bloc de code particulier des années plus tard, il comprendra le code et s'en tiendra aux normes attendues. CakePHP n'est pas différent et j'espère que ce guide vous aidera à corriger certaines mauvaises habitudes.