Améliore ta productivité sur tes projets PHP

Pour chaque nouveau projet sur lequel je dois travailler, je commence toujours par ajouter au moins 3 librairies pour faciliter mon travail.

• PHPStan - Un outil d'analyse statique.
• Psalm - Un outil d'analyse statique avancé.
• Easy Coding Standard - Un ensemble de règles pour Simplify/EasyCodingStandard.

Ils sont devenus mes meilleurs amis avec PHPStorm afin de refactoriser chaque morceau de code.

Pourquoi avez-vous besoin d'analyseur statique ?

Tout d'abord, si vous n'êtes pas familier avec les outils d'analyse statique, laissez-moi vous expliquer ce qu'ils sont. Vous écrivez des interfaces, des classes, des méthodes, etc. en PHP. Tout ce code est orchestré pour créer de belles applications. Mais vous devez savoir qu'en ajoutant de nouvelles fonctionnalités, vous pouvez créer des bugs potentiels. C'est là que ces outils entrent en jeu.

Les outils d'analyse statique sont des programmes qui analysent les bases de code sans les exécuter. Vous pouvez trouver beaucoup de ces outils en ligne. Par exemple, il y a une page Wikipedia qui liste tous les projets connus.

Ils analyseront tout votre code et tenteront de trouver des erreurs potentielles grâce aux types et à l'AST.

Liste d'outils d'analyse statique de PHP

Si vous n'êtes pas encore convaincu, voici un autre point de vue sur PHPStan :

Comment configurer PHPStan pour les applications Symfony

Aujourd'hui, je ne peux pas imaginer développer des applications PHP modernes sans que PHPStan fonctionne au niveau maximum avec de nombreuses vérifications. Il aide à prévenir de nombreux problèmes pendant le développement et le remaniement des applications.

Pourquoi avez-vous besoin d'une librairie de style de code ?

EasyCodingStandard se décrit lui-même comme "le moyen le plus simple de commencer à utiliser PHP CS Fixer et PHP_CodeSniffer avec 0 connaissance". Ces deux sous-packages permettent à votre équipe de créer un ensemble de règles de style à suivre pendant la durée du projet.

Même si vous travaillez seul, vous pouvez tirer parti de cet outil. Pensez aux projets que vous avez laissés de côté pendant quelques mois.

Maintenant, comment l'utiliser automatiquement ?

Vous n'aurez besoin que de ces deux commandes à exécuter :

• vendor/bin/phpstan analyse src --level=max
• vendor/bin/ecs check src --fix

Step 1 : Faire simple

Ecrivez un Makefile :

app@tests: app@lint-php app@quality-tests

app@lint-php:
	vendor/bin/ecs check src

app@lint-git-diff:
	vendor/bin/ecs check $$(git diff --name-only --diff-filter=ACMRTUXB HEAD~..HEAD -- '*.php')

app@lint-php-fix:
	vendor/bin/ecs check src tests --fix

app@quality-tests: app@php-analysis

app@php-analysis:
	vendor/bin/phpstan analyse src --level=max
	vendor/bin/psalm

Vous pouvez aussi le faire fonctionner avec les scripts composer et tout autre outil qui vous est familier.

Utilisez ensuite make app@tests pour être capable de repérer le code PHP sujet aux erreurs que vous avez écrit. Ou utilisez GrumPHP pour ajouter des hooks pre-commit si vous voulez appliquer des règles avant chaque commit. Vous pouvez également suivre la partie suivante sur Gitlab-CI.

Étape 2 : Chaque push doit être suivi d'une validation sur votre CI

Mais pour être sûr de vraiment automatiser toutes les choses, écrivez un fichier .gitlab-ci.yml. Il sera votre meilleur ami avant de merger les Merge Requests :D

image:
  name: 'your-super-duper-php-docker-image' # Ou n'importe quelle image Docker
  entrypoint: ['']

before_script:
  - composer install --prefer-dist --no-progress --no-suggest --no-interaction

variables:
  CI_DEBUG_TRACE: 'false'
  GIT_SSL_NO_VERIFY: 'true'

tests:
  tags:
    - 'docker'
  script:
    - composer validate --no-check-publish
    - php bin/console security:check composer.lock --end-point=https://security.symfony.com/check_lock # Si vous travaillez sur un projet Symfony
    - vendor/bin/ecs check $(git diff --name-only --diff-filter=ACMRTUXB HEAD~..HEAD -- '*.php')
    - php vendor/bin/phpstan analyse src --level=max

Si vos Jobs de CI sont rouges, vous devez bloquer tout merge avant une nouvelle validation.

Je préfère vérifier le style de code uniquement pour le git diff pour les vieux projets avec beaucoup de code smells. Cela facilite également la review de vos MR/PRs car vous ne modifiez pas de fichiers sans rapport.

Je n'applique pas encore les règles de Psalm. Je viens juste de commencer à travailler avec lui sur des projets plus récents. Cependant, il a une meilleure compréhension de PHPDoc, un ensemble spécifique d'annotation, templating, assertions et d'excellents outils de refactoring de projets php.

Avec cette ensemble d'outils, vous êtes prêt à travailler rapidement mais avec une ceinture de sécurité plutôt cool ! En outre, vous pourriez ajouter des "smoke tests" avec PHPUnit à votre projet d'API/site web/CLI pour commencer doucement dans le monde des tests unitaires. 💪

Honnêtement, j'aimerais bien savoir quels sont les outils équivalents les plus utilisés pour C# !