Lorsque je commence à développer une nouvelle application, j’ai pris l’habitude de tout de suite effectuer quelques actions et de mettre en place des outils. Je vous propose donc de les partager avec vous.

Versionner avec Git

Première chose que je fais, je versionne mon projet en local. L’avantage avec git est que cela se fait en une seule commande. Rien de plus simple pour initialiser mon projet : je me place dans le répertoire de mon projet et j’exécute la commande suivante :

git init

Voilà, c’est fait ! Je peux désormais versionner mon application au fur et à mesure et revenir en arrière si besoin. Et si je le souhaite, je pourrai le sauvegarder ou le partager plus tard sur un serveur (comme GitHub, par exemple).

Mise en place d'un autoloader de classes

PHP, comme d'autres langages, possède une notion d'espace de nom. Pour citer la documentation :

Les espaces de noms PHP fournissent un moyen pour regrouper des classes, interfaces, fonctions ou constantes.

Afin de pouvoir utiliser facilement ces espaces de nom, il est nécessaire d'utiliser un autoloader. Et ça tombe bien, un outil permet d'en générer un simplement : composer.

Composer est un outil de gestion de dépendances qui apporte aussi plein d'autres fonctionnalités comme fournir un autoloader.

• Initialisation d'un projet avec composer

composer init

Appuyez sur entrée à la question : "Add PSR-4 autoload mapping? Maps namespace "Jimmy\Project" to the entered relative path. [src/, n to skip]:" pour mettre en place l'autoloader.

• Il suffira juste ensuite d'inclure le script généré dans le point d'entrée de notre application

include_once('./vendor/autoload.php');

Choisir une norme d’écriture de code

Après quelques années à écrire du code sans réelle règle, je me suis aperçu que lorsqu’on travaillait en équipe, les manières d’écrire le code variaient beaucoup d’une personne à l’autre. Et cela s’est beaucoup plus ressenti lorsque, dans mon travail, nous avons commencé à faire de la review de code. Les différentes façons d'écrire rendait la relecture un peu plus difficile. Nous avons donc choisi une norme d’écriture que nous suivons.

L’autre avantage est que si vous développez une application open-source, vous pourrez indiquer à vos éventuels contributeurs de respecter la norme choisie afin d'avoir un code uniforme.

J’applique désormais tout le temps pour chaque nouveau projet une norme d’écriture. Je passe par plusieurs moyens pour la contrôler :

• Je configure mon IDE pour qu'il analyse mon code en temps réel (j'utilise intelliJ ou PHPStorm)
• Je lance aussi manuellement avant de commiter mon développement un outil qui scanne tout mon code source pour vérifier si la norme choisie est bien appliquée.

L'outil que j'utilise est PHP_CodeSniffer (phpcs). Pour l'installer et l'utiliser, suivez les instructions suivantes :

• Installation via composer

composer require --dev squizlabs/php_codesniffer

• Création d'un fichier de configuration .phpcs.xml

<?xml version="1.0"?>
<ruleset>
    <rule ref="PSR12"/>
    <file>src/</file>
    <arg name="colors"/>
</ruleset>

• Il ne vous reste plus qu'à lancer :

vendor/bin/phpcs

L'avantage d'avoir un outil en ligne de commande est qu'il peut être lancé automatiquement via un hook git ou par un serveur d'intégration continue.

Choisir un outil de tests unitaires

Même si je ne pratique pas strictement le TDD, je mets tout de suite en place un outil de tests unitaires. Tant qu’à être dans la configuration de mon projet, autant le faire même si mes premiers développements ne sont pas forcément testés. Au moins je n’ai aucune excuse pour ne pas écrire de tests. De la même manière que pour la norme d'écriture, j'exécute mes tests unitaires en ligne de commande et pourrais donc facilement le lancer automatiquement. J'utilise pest.

• Installation :

composer require --dev pestphp/pest 

• Configuration via un fichier phpunit.xml

<?xml version="1.0" encoding="UTF-8"?>
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="./vendor/phpunit/phpunit/phpunit.xsd"
         bootstrap="vendor/autoload.php"
         colors="true"
         cacheResultFile="./var/cache/"
>
    <testsuites>
        <testsuite name="Test Suite">
            <directory suffix="Test.php">./tests</directory>
        </testsuite>
    </testsuites>
    <coverage processUncoveredFiles="true" cacheDirectory="./var/cache/">
        <include>
            <directory suffix=".php">./src</directory>
        </include>
    </coverage>
</phpunit> 

• Créer le dossier qui contiendra les tests

mkdir tests

• Créer le dossier qui contiendra le cache des tests ainsi que des fichiers pour git

mkdir -p var/cache
touch var/cache/.gitkeep

• Je vous conseille de rajouter dans le fichier .gitignore les lignes suivantes (la première ligne est normalement déjà présente) :

/vendor/
.phpunit.result.cache
!var/cache/.gitkeep
var/cache/*

• Lancement :

vendor/bin/pest

Modèle prêt à l'emploi

Afin d'éviter à refaire à chaque fois toute cette configuration, j'ai créé un projet template pour PHP : https://github.com/klnjmm/template-php

git clone https://github.com/klnjmm/template-php.git
cd template-php

• Modifier dans le fichier composer.json les différentes informations générales (nom et description du projet)
• Puis lancer

make init
make up

Voilà il ne vous reste plus qu'à coder !

Ressources

• Template-PHP : https://github.com/klnjmm/template-php.git
• Git : https://git-scm.com
• Composer : https://getcomposer.org
• PHP Code Sniffer : https://github.com/squizlabs/PHP_CodeSniffer
• Pest : https://pestphp.com/