L'auteur montre qu’il n’est pas nécessaire de migrer vers TypeScript pour bénéficier de sa rigueur : PHP 8.1+, couplé à des outils d’analyse statique (Psalm, PHPStan) et à des bibliothèques idiomatiques, permet d’obtenir des garanties similaires en typage, validation et maintenabilité. L’article détaille des équivalences concrètes : DTOs (classes typées + validation runtime), énumérations (PHP enums + match), génériques (via docblocks et analyse statique), métadonnées (attributs PHP), validation (Symfony Validator), gestion des erreurs (objets Result ou exceptions), et asynchrone (queues ou Fibers). L’approche est incrémentale, avec des exemples prêts à l’emploi, et met en avant les forces de PHP (écosystème mature, performances) tout en comblant l’écart avec TypeScript sur la sécurité et l’ergonomie. À retenir : combiner typage statique, validation aux frontières et design explicite pour un code PHP aussi robuste et maintenable qu’une base TypeScript, sans tout réécrire.
L'article propose une méthode structurée pour mettre à jour un projet Symfony en toute confiance. Il recommande d'utiliser des outils comme Bruno pour tester les routes, de mettre à jour les dépendances et les outils, d'appliquer des analyses statiques avec PHPStan, et de refactorer le code avec Rector. L'article insiste sur l'importance des tests automatisés et des mises à jour progressives pour éviter les régressions.
Il s'agit d'une extension PHPStan pour vérifier que le code respecte la règle de puissance de 10 de la NASA (cf https://fr.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code). Les 10 règles sont :
1°) Éviter les constructions de flux complexes, telles que goto et récursivité .
2°) Toutes les boucles doivent avoir des limites fixes. Cela évite de créer involontairement des boucles infinis.
3°) Éviter d'allouer de la mémoire sur la heap.
4°) Limiter les fonctions à une seule page affichable sur un écran.
5°) Utiliser un minimum de deux assertions par fonction.
6°) Limiter la portée des variables au plus petit possible.
7°) Vérifier la valeur de retour de toutes les fonctions non-void ou transformer en void pour indiquer que la valeur de retour est inutile.
8°) Utiliser le préprocesseur avec parcimonie.
9)) Limiter l'utilisation du pointeur à un seul déréférencement et ne pas utiliser de pointeur de fonction.
10°) Compiler avec tous les avertissements possibles actifs ; tous les avertissements doivent alors être pris en compte avant la publication du logiciel.
Tout est dans le titre
Tout est dans le titre
Création d'une règle custom pour PHPStan
Tout est dans le titre
Tout est dans le titre
Des astuces autour du typage des arrays en PHP (notamment pour l'analyse statique avec PHPStan)
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
L'auteur donne de bons conseils sur divers sujets :
- VCS (commits atomiques, etc.),
- adoption d'un standard de code corrigé / validé par PHPCS Fixer,
- utilisation d'outils d'analyse statique (PHPStan, Psalm) et de "mutation testing" (Infection)
- automatisation du déploiement
- living documentation, notamment avec Gherkin
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre, sauf que ça concerne PHP - à retenir, l'acronyme RIPP (Rector, Infection, PHPStan, Psalm) qui désigne des outils bien utiles pour le refactoring. L'auteur parle aussi de blackfire
Tout est dans le titre
Tout est dans le titre... sauf que ça concerne l'utilisation de PHPStan
Tout est dans le titre
Tout est dans le titre