4 astuces que respecte n'importe quel expert Laravel

Il est tellement facile de laisser un projet moisir au fond du tiroir une fois qu’il est déployé en production.

Mais un beau jour, votre client finira par revenir vers vous. Il voudra faire évoluer son projet. Malheureusement, votre code est devenu incompréhensible et il est devenu très simple de provoquer des régressions. C’est normal, rares sont ceux qui possèdent une mémoire infaillible. La livraison devient un enfer et vous n’avez qu’une seule envie : faire subir à votre client les pires châtiments imaginables.

Attention cependant : ce n’est pas la faute de votre client si la situation a échappé à votre contrôle.

Voyons ensemble ce que vous pouvez faire dès maintenant pour changer ça.

Utilisez des packages open source

Croyez-en mon expérience : utiliser du code testé et éprouvé par la communauté donnera presque toujours de bien meilleurs résultats que ce que vous aurez vous-même pondu. Pourquoi ?

Un package open source est développé par une multitude de personnes très intelligentes ;
Il est testé et éprouvé par la communauté. Selon la popularité du package, le nombre d’individus se chiffre en dizaines de milliers ;
Enfin, il est documenté. Et ne me dites pas que vous documenterez votre code plus tard ! Vous aurez la flemme, comme presque tout le monde, et ce seront vos remplaçants qui en pâtiront.

Alors à partir de maintenant, faites donc ça. Je vous garanti que cela paiera très vite.

Formatez automatiquement votre code

OK. Le premier qui n’applique pas ce conseil sera exilé sur une île déserte sans connexion à internet.

Personnellement, j’utilise un outil appelé PHP CS Fixer, couplé à Visual Studio Code via cette extension.

Installez PHP CS Fixer globalement avec Composer :

composer global require friendsofphp/php-cs-fixer

Ensuite, créez votre fichier de configuration .php-cs-fixer.php à la racine de votre projet. Exemple :

<?php
 
$finder = PhpCsFixer\Finder::create()
    ->exclude(['bootstrap/cache', 'storage']);
 
return (new PhpCsFixer\Config())
    ->setFinder($finder)
    ->setRules([
        '@Symfony' => true,
        'cast_spaces' => ['space' => 'single'],
        'combine_consecutive_issets' => true,
        'combine_consecutive_unsets' => true,
        'compact_nullable_typehint' => true,
        'concat_space' => ['spacing' => 'one'],
        'date_time_immutable' => true,
        'declare_equal_normalize' => true,
        'new_with_braces' => false,
        'no_empty_comment' => false,
        'no_superfluous_elseif' => true,
        'not_operator_with_successor_space' => true,
        'ordered_imports' => ['sort_algorithm' => 'length'],
        'ordered_interfaces' => true,
        'ordered_traits' => true,
        'php_unit_method_casing' => false,
        'return_type_declaration' => ['space_before' => 'one'],
        'single_space_after_construct' => true,
        'single_trait_insert_per_statement' => false,
    ]);

Si l’extension est bien configurée, alors votre code sera formaté à chaque fois que vous sauvegarderez votre document.

L’avantage d’avoir fait tout ça ? Vos collaborateurs aussi pourront en profiter.

Commentez votre code

Haha ! Je vous vois déjà arriver :

Tant que ton code est bien écrit, il n’y a pas besoin de le commenter !

Et bien non ! Comme tout dans cet univers, ça dépend. Alors attention, Il vaut mieux ne pas commenter son code si c’est pour faire ce genre d’infamie :

// Create user.
User::factory()->create();

Ce commentaire ne sert à rien. C’est de la décoration. Et j’avoue m’être rendu coupable de ça un nombre de fois incalculable dans ma carrière.

Prenons plutôt un bon exemple tout droit sorti de la codebase de Larabiz :

Subscriber::create($input)->notify(new ConfirmSubscription);

Ça coule de source, non ? Ce code n’a absolument pas besoin d’être commenté.

Maintenant, prenons du code issu d’un autre de mes projets :

// Create an incomplete purchase (meaning there's no start and end dates until the payment succeeded).
$purchase = Purchase::factory()->incomplete()->create([
    'opening_id' => $this->opening->id,
    'boost_id' => $this->boost->id,
]);
 
// Let's pretend Stripe called our web hook.
$job = new BoostOpening(new WebhookCall(['payload' => ['data' => ['object' => ['id' => $purchase->checkout_session_id]]]]));
$job->handle();
 
// After the job did its job (🥁), the purchase should
// have a start date that equals to right now().
$this->assertEquals(
    now()->toDateTimeString(),
    ($purchase = $purchase->fresh())->starts_at
);
 
// … and an end date which equals to now + the boost's duration in days.
$this->assertEquals(
    now()->addDays(\$this->boost->days)->toDateTimeString(),
    $purchase->ends_at
);
 
// Then, the opening should detect it's been boosted.
$this->assertEquals(1, $this->opening->purchases()->count());

Il s’agit d’un test automatisé. Il est très compliqué de rendre lisible ce genre de code. Dans le cas présent, le mieux est de communiquer ses intentions. Et croyez-moi, remettre les mains dans une codebase commentée après ~~quelques mois~~ semaines sans y avoir touché, c’est un véritable bonheur.

Respectez les conventions de Laravel

Sortir des sentiers battus est une excellente chose et je vous encourage vivement à le faire. Mais comme je l’ai dit plus haut, tout dépend du contexte.
Ici, le mieux est de coller au maximum avec ce que vous préconise Laravel. Ne chamboulez pas sa structure et utilisez au maximum toutes les fonctionnalités qu’il vous offre. Ainsi, vous pourrez :

Faciliter la collaboration avec les développeurs qui connaissent Laravel aussi bien que vous ; (Eh oui, car vous aurez à nouveau la flemme de documenter tous les trucs farfelus que vous aurez inventés !)
Bénéficier d’améliorations en même temps que le framework évolue.

Conclusion

Il y a encore bien plus que vous pourriez faire pour faciliter votre vie de développeur, ainsi que celle de vos collègues. Mais nous verrons cela une prochaine fois. Le but de cet article était de vous donner des conseils facilement applicables à vos projets.

À bientôt ! 👋