Maintenir un projet en PHP : 5 erreurs à éviter

PHPcomme d'autres langages, présente des inconvénients qui ne sont pas négligeables lorsqu'il s'agit de gérer un système d'information. IT projet où PHP est la langue principale.

Nous en avons dressé une liste ci-dessous, assortie de conseils pour les éviter.

1. Non-respect des recommandations de la norme PHP

PHP est considéré comme un "langage facile" car il présente une très faible barrière à l'entrée. Il en résulte une grande disparité dans les normes de codage et dans la manière dont les interfaces globales sont mises en œuvre dans diverses bibliothèques externes. Dans un effort pour mettre de l'ordre, un ensemble de normes a été introduit. Celles-ci décrivent un ensemble de moyens par lesquels le développeur de l'implémentation peut satisfaire n'importe quel ensemble de contraintes exigées par la norme. Un exemple simple pour Répartiteur d'événements:

Auditeur - Un auditeur est un PHP qui s'attend à recevoir un événement. Le même événement peut être transmis à zéro ou plusieurs auditeurs. Un auditeur PEUT mettre en file d'attente un autre comportement asynchrone s'il le souhaite.

Grâce à cette norme, tous les développeurs qui utilisent la nomenclature des PSR peuvent facilement non seulement communiquer, mais aussi code avec d'autres développeurs.
La mise en pratique de ces normes, par exemple par l'utilisation de PHP La bonne méthode les lignes directrices et les bibliothèques qui prennent en charge les interfaces globales de PSR, permet Développeurs PHP de s'adapter plus rapidement à l'évolution des exigences fonctionnelles, architecturales et infrastructurelles.

Comment l'éviter ?

En tant que mainteneur de la base de code, n'oubliez jamais d'utiliser des versions éprouvées et stables des bibliothèques externes et, si vous êtes obligé d'utiliser une solution personnalisée, mettez-la en œuvre en utilisant des PSR PHP.
Une liste de toutes les normes disponibles est disponible sur le site web principal PHP-FIG. Des normes étendues avec des descriptions pratiques sont disponibles sous différents formats auprès de l'Agence européenne pour la sécurité et la santé au travail (ESA). PHP La bonne méthode page d'accueil.
Les meilleures bibliothèques conformes aux normes PHP-FIG sont répertoriées sur la page PHP Ligue site web.

2. Ne pas verrouiller les versions des dépendances dans composer.json

Dans les projets qui utilisent le gestionnaire de dépendances Compositeur il arrive souvent qu'après une longue période de soutien et d'entretien de la produit dans l'environnement de production, il est nécessaire de mettre en œuvre des changements fonctionnels sans reconstruire l'ensemble de l'architecture. Le plus souvent, le projet est alors pris en charge par un programmeur, dont la tâche consiste à lancer l'environnement de développement local et à commencer à travailler sur des tickets. En se basant sur les composer.lock le développeur est en mesure de restaurer le projet dans l'état où il se trouvait dans l'environnement de production, mais toute modification du fichier composer.json par exemple en ajoutant la bibliothèque, provoquera une cascade d'erreurs qui augmenteront le temps réel de mise en œuvre d'un nouveau fichier équipe à l'organisation ainsi que le temps de développement de la solution.

Comment l'éviter ?

Une fois que l'application est stable, le responsable du code doit verrouiller les versions des bibliothèques dans le fichier composer.json et créer une procédure claire décrivant comment mettre à jour leurs versions si nécessaire à l'avenir.

Envisagez également de mettre en place un mécanisme permettant de vérifier l'état de sécurité des bibliothèques utilisées et d'automatiser le processus de mise à disposition des mises à jour de sécurité.
En utilisant des outils gratuits tels que DépendanteNous pouvons ainsi maintenir une infrastructure de version cohérente et gérable pour les bibliothèques dépendantes et fournir une garantie de sécurité pour notre application.

3. Mauvaise collecte des exigences

> Ce n'est qu'un CRUD, pourquoi s'en préoccuper ?

> Il existe une bibliothèque qui fait exactement cela !

Dans le cadre de la PHP il est facile de tomber dans le tourbillon de l'oubli lors de la mise en œuvre de la logique commerciale d'un produit. Au fil des ans, des centaines de projets ont été réalisés pour [créer des panneaux administratifs pour gérer les modèles de données] (https://backpackforlaravel.com/), [générer des vues de type Google Analytics] (https://github.com/Kunstmaan/KunstmaanDashboardBundle) ou [résoudre les problèmes asynchrones de PHP] (https://laravel.com/docs/9.x/octane) d'un simple coup de baguette magique (OK, avec une simple requête en ligne de commande).
Le monde PHP est plein d'implémentations prêtes à l'emploi qui fonctionnent 99,9% du temps.
Ce 0.1% est l'endroit où la logique commerciale entre en conflit avec les limites fonctionnelles des bibliothèques utilisées.
C'est ce qu'il est convenu d'appeler les "throw-ins" qui sont les plus difficiles à mettre en œuvre à la fin du projet.

Comment l'éviter ?

Il n'y a aucune chance de trouver le juste milieu entre l'ingénierie excessive et l'ingénierie insuffisante sans une bonne compréhension du domaine d'activité du produit.
En commençant équipe de développement en amont de la phase de développement du produit et en travaillant de manière proactive avec le propriétaire du produit, vous pouvez minimiser le risque d'utiliser une solution qui ne fonctionnera pas en tant qu'investissement à long terme.

4. Réduire les coûts en évitant d'écrire des tests

PHP n'est pas parfait, c'est certain. Ses lacunes en termes de typage statique, de manque de prise en charge des génériques et de prise en charge continue de méthodes archaïques sont encore une source de plaisanteries parmi les programmeurs. Cependant, depuis quelque temps Développeurs PHP ont été dotés d'outils de plus en plus puissants, tels que PHPStan, Xdebug, PHP-CS-Fixer qui leur permettent de maintenir la cohérence et le typage statique, évitant ainsi de nombreux bogues. Pourtant, trop peu d'attention est accordée aux tests et ceux-ci, lorsqu'ils sont mis en œuvre correctement, se traduisent par un retour sur investissement rapide sous la forme de
- réduction des erreurs de régression
- une meilleure connaissance des capacités des produits
- accroître le sentiment d'appropriation du code par les développeurs

Comment l'éviter ?

Ne faites pas d'économies sur les tests. Écrire des scripts Behat simples n'est pas si difficile, vous n'avez pas besoin d'écrire des tests complexes de bout en bout tout de suite ou d'entrer dans les détails de l'implémentation et de tester chaque méthode à l'unité.
Un simple test Behat décrit en langage naturel vaut souvent plus que le test de bout en bout le plus méticuleusement écrit.

5. Ne pas tenir compte des modèles d'architecture modernes

Les Langue PHP et ses deux cadres les plus puissants Laravel et Symfony sont parfaitement adaptés à la création d'une architecture moderne, fonctionnelle et, surtout, très performante. La prise en charge de divers systèmes de file d'attente de messages et la rapidité toujours plus grande de la technologie PHP L'amélioration des performances d'une version à l'autre nous permet de créer facilement des microservices basés sur des microfabriques. Cependant, la plupart du temps, nous continuons à nous appuyer sur des systèmes monolithiques. Il n'y a rien de mal à cela, mais lorsque nous envisageons le développement de tels systèmes, nous devons accorder une attention particulière aux limites du domaine et déterminer le point d'interface entre les nouvelles solutions et les parties plus anciennes du système.

Comment l'éviter ?

Lors de l'élaboration de toute PHP il vaut la peine d'examiner de près les solutions actuelles, de créer des interfaces globales pour la communication des données et de mettre en œuvre de nouvelles fonctionnalités en utilisant les techniques et les pratiques les plus récentes. L'une des solutions les plus utilisées dans la pratique est la suivante Motif de l'étrangleur.