J’ai déjà partagé quelques unes des prochaines fonctionnalités de PHP 7, dans cet article, j’ai pensé jeter un coup d’œil à certains des mauvais modèles que nous devrions arrêter d’utiliser comme nous passons à PHP 7. Et n’oubliez pas de jeter un coup d’œil à notre nouveau méga-benchmark de la version finale de PHP 7.2.
Les meilleures pratiques de PHP 7, autrement dit ce qu’il ne faut pas faire en PHP 7
- Ne pas utiliser les fonctions mysql_
- Ne pas écrire de code inutile
- Ne pas utiliser les balises de fermeture PHP
- Ne pas passer par la référence si ce n’est pas nécessaire
- Ne pas effectuer de requêtes dans une boucle
- Ne pas utiliser * dans les requêtes SQL
- Ne pas faire confiance aux données de l’utilisateur
- Ne pas essayer d’être malin
- Ne pas réinventer la roue
- Ne pas négliger les autres langues
1. Ne pas utiliser les fonctions mysql_
Le temps est enfin venu où il ne sera pas avisé d’utiliser les fonctions mysql_. PHP 7 les supprimera complètement du noyau, ce qui signifie que vous devrez passer aux fonctions mysqli_ bien meilleures, ou à l’implémentation encore plus flexible du PDO.
2. Ne pas écrire de code inutile
Ceci est peut-être simple, mais cela deviendra de plus en plus important parce que les augmentations de vitesse en PHP 7 peuvent cacher certains de vos problèmes. Ne vous contentez pas de la vitesse de votre site simplement parce que le passage à PHP 7 l’a rendu plus rapide.
Pour comprendre l’importance de la vitesse et ce que vous pouvez faire pour améliorer les choses, jetez un coup d’œil à notre guide d’initiation à l’optimisation de la vitesse.
En tant que développeurs, vous devez toujours vous assurer de ne charger les scripts que lorsqu’ils sont nécessaires, de les concaténer si possible, d’écrire des requêtes de base de données efficaces, d’utiliser la mise en cache lorsque c’est possible, et ainsi de suite.
Pour un coup de pouce rapide et facile à votre optimisation globale, pensez à minifier votre code. Kinsta a intégré une fonction de minification du code directement dans le tableau de bord MyKinsta, permettant aux clients d’activer la minification automatique de CSS et JavaScript d’un simple clic.
3. Ne pas utiliser les balises de fermeture PHP à la fin d’un fichier
Si vous jetez un coup d’œil, la plupart des fichiers du noyau de WordPress omettent la balise PHP de fin quand un fichier se termine par du code PHP. En fait, le framework Zend en particulier l’interdit. Il n’est pas nécessaire par PHP et en l’omettant à la fin d’un fichier, vous vous assurez qu’aucun espace ne peut être ajouté.
4. Ne passez pas par la référence si ce n’est pas nécessaire
Personnellement, je n’aime pas passer par la référence. Je comprends que dans certains cas, c’est utile, mais dans beaucoup d’autres, cela rend le code plus difficile à comprendre, à suivre et surtout à prédire le résultat.
Apparemment, les gens pensent que cela rend leur code plus rapide, ce qui, d’après des programmeurs PHP respectables n’est tout simplement pas vrai.
Un exemple de la raison pour laquelle les références sont mauvaises est que PHP est construit en shuffle() ou sort(). Au lieu de renvoyer un tableau mélangé ou trié, ils modifient l’original, ce qui est complètement illogique à mon avis.
5. Ne pas effectuer de requêtes dans une boucle
Effectuer des requêtes de base de données dans une boucle est un gaspillage. Cela met inutilement à rude épreuve vos systèmes et il est probable que vous obtiendrez le même résultat plus rapidement à l’extérieur de la boucle. Lorsque je me heurte à une situation où cela serait nécessaire, je peux généralement résoudre le problème avec deux requêtes séparées que j’utilise pour construire un tableau de données. Je boucle alors sur le tableau, pas besoin d’effectuer des requêtes dans le processus.
En raison de la façon dont WordPress fonctionne, il peut y avoir quelques exceptions à cette règle. Tandis que get_post_meta() récupérera une méta-valeur à partir de la base de données vous pouvez l’utiliser dans une boucle si vous parcourez les métadonnées d’un article spécifique. En effet, lorsque vous l’utilisez pour la première fois, WordPress récupère toutes les métadonnées et les met en cache. Les appels suivants utilisent les données mises en cache, et non les appels à la base de données.
La meilleure façon de résoudre ces problèmes est de lire la documentation de la fonction et d’utiliser quelque chose comme la commande Query Monitor.
6. Ne pas utiliser * dans les requêtes SQL
D’accord, ceci est plus un problème MySQL, mais nous avons tendance à écrire notre code SQL en PHP donc je dis que c’est un jeu équitable. Dans tous les cas, n’utilisez pas de caractères génériques dans les requêtes SQL si vous pouvez les éviter, surtout si vous avez une base de données avec beaucoup de colonnes.
Spécifiez les colonnes exactes dont vous avez besoin et ne récupérez que celles-ci. Cela permet de minimiser l’utilisation de vos ressources, de protéger vos données et de rendre les choses aussi claires que possible.
À propos de SQL, connaissez vos fonctions disponibles et testez la vitesse autant que possible. Pour calculer des moyennes, des sommes ou des nombres similaires, utilisez des fonctions SQL au lieu des fonctions PHP. Si vous n’êtes pas sûr de la vitesse d’une requête, testez-la et essayez d’autres variantes – utilisez la meilleure.
7. Ne pas faire confiance aux données de l’utilisateur
Il n’est pas sage de se fier aux données des utilisateurs. Filtrez, assainissez, échappez, vérifiez et utilisez toujours des solutions de rechange. Il y a trois problèmes avec les données des utilisateurs : nous, les développeurs, ne prenons pas toutes les possibilités en compte, c’est souvent incorrect et c’est peut-être intentionnellement malveillant.
Un système bien conçu peut vous protéger contre tout cela. Assurez-vous d’utiliser des fonctions intégrées comme filter_var() pour vérifier les valeurs correctes et les fonctions d’échappement et autres lorsque vous travaillez avec des bases de données.
WordPress a un tas de fonctions pour vous aider. Jetez un coup d’œil à l’article sur la validation, l’échappement et l’assainissement des données utilisateur pour plus d’informations.
8. N’essayez pas d’être malin
Votre but devrait être d’écrire un code élégant qui exprime le plus clairement vos intentions. Vous pouvez peut-être économiser 0,01 seconde de plus par page en raccourcissant tout à une seule variable de lettre, en utilisant une logique ternaire à plusieurs niveaux et d’autres astuces, mais ce n’est vraiment rien comparé aux maux de tête que vous allez vous causer à vous-même et à tous ceux qui vous entourent.
Nommez vos variables de façon appropriée, documentez votre code, choisissez la clarté plutôt que la brièveté. Mieux encore, utilisez un code orienté objet standardisé qui se documente sans avoir besoin de beaucoup de commentaires en ligne.
9. Ne pas réinventer la roue
PHP existe depuis longtemps, les sites Web sont faits depuis encore plus longtemps. Il y a de fortes chances que ce que vous devez faire, quelqu’un l’a déjà fait. N’ayez pas peur de vous appuyer sur les autres pour obtenir du support, Github est votre ami, Composer est votre ami, Packagist est votre ami.
Des loggers aux outils de manipulation des couleurs, des profileurs aux cadres de tests unitaires, des API Mailchimp aux APIs Twitter Bootstrap, tout est disponible sur simple pression d’un bouton (ou saisie d’une commande), utilisez-les !
10. Ne négligez pas les autres langues
Si vous êtes un utilisateur PHP, il est maintenant pratique courante de connaître au moins HTML, CSS, Javascript et MySQL. Quand vous avez une bonne maîtrise de ces langues, il est temps d’apprendre à nouveau le Javascript. Javascript n’est pas jQuery. Vous devez apprendre Javascript correctement pour pouvoir l’utiliser efficacement.
Je recommanderais également d’apprendre tout sur le PHP orienté objet, c’est un sauveur de vie et rendra votre code meilleur par ordre de grandeur. Il vous ouvrira aussi les portes de langages comme C# et Java, ils seront beaucoup plus faciles à comprendre avec OOP à votre ceinture.
Élargissez vos connaissances en vous familiarisant avec les gestionnaires de paquets, les scripts de construction, Coffeescript, LESS, SASS, YAML, les moteurs de template et autres outils géniaux. Je recommanderais vivement d’envisager d’autres frameworks PHP, Laravel en particulier.
Quand vous vous débrouillez plutôt bien avec ça, qu’en est-il de Ruby, Ruby on Rails, le développement d’applications pour Android, iPhone, Windows Phone ? Vous pensez qu’il n’y a pas de raison d’être parce qu’ils se situent en dehors de votre zone de confort et de vos besoins professionnels, mais c’est justement le but. Chaque langue a quelque chose d’utile à enseigner et un peu plus de connaissances ne fait jamais de mal. Ce n’est pas un hasard si tous les meilleurs développeurs PHP en savent beaucoup sur les autres langages de programmation !
Hi, my name is Daniel, I'm the CTO here at Kinsta. You may know me from Smashing Magazine, WPMU Dev, Tuts+ and other WordPress/Development magazines. Aside from WordPress and PHP I spend most of my time around Node, React, GraphQL and other technologies in the Javascript space.
When not working on making the best hosting solution in the Universe I collect board games, play table football in the office, travel or play guitar and sing in a pretty bad band.
Laisser un commentaire