🙋 Petit sondage

• Qui pense que la qualité, ce n'est pas important ?
• Qui a déjà entendu un collègue lui dire :
  "Haaaa ! C'est bon, ça marche"
• Qui pense que la qualité, ça coûte cher ?
• Pour vous, c'est quoi LA Qualité ?

Essayons de définir LA Qualité.

Wikipédia

Wikipédia

Ok... Oui... Euh... Mais encore.

Et si on demandait directement aux utilisateurs ?

PS : merci les LLM. _{(J'ai peut-être ajouté d'aller un peu dans la caricature.)}

Développeur passionné

"LA Qualité, c'est quand mon code est tellement propre et bien testé que je peux le relire six mois après en me disant 'putain, bien joué' au lieu de pleurer."

Maxime le "développeur"

"Haaaa ! C'est bon, ça marche..."

PO

"LA Qualité, c'est quand toutes les user stories passent en 'Done' avant la fin du sprint."

Client

"LA Qualité, c'est quand ça fait exactement ce que je veux, que ça marche du premier coup, et que ça ne coûte pas plus cher que prévu."

La secrétaire à 2 ans de la retraite

"LA qualité, c'est quand ça marche comme avant."

Patron d'une société éditrice de logiciel

"LA qualité ? C'est quand mes clients renouvellent leur licence sans négocier."

Manager payé à la performance

"LA Qualité, c'est livrer dans les temps et sous budget - peu importe ce qui se passe après."

Et donc...

Ma vision

Revenons à notre sondage.

Oui, vous avez tous raison. Mais...

Vous avez tous tort.

LA Qualité n'est pas un état, mais un processus.

• L'immobilisme en informatique c'est reculer.
• On peut TOUJOURS faire mieux.
• Chercher à faire mieux qu'hier.

Explorons quelques pistes d'amélioration.

En vrac, c'est pour le plaisir.

⚠️ Avant de commencer un petit avertissement.

Oui. Je sais. Il y a des exceptions.

Mais attention à ne pas les transformer en règles.

Les tests

NON

On va parler de couverture de code

Ou plus exactement de la quantification de LA Qualité.

Pourquoi quantifier LA Qualité ?

• Car les chiffres sont plus simples à manipuler.
• Car on doit communiquer.
• Car on travaille en équipe.

=> Mais c'est un piège.

Comment quantifier ce que l'on a déjà du mal à définir ?

• On se focalise sur quelques chiffres.
• Ce qui n'est pas quantifiable n'est pas pris en compte.
• On met des objectifs (70 % de couverture de code, 25 % de commentaires, nombre de jours sur de la dette...)

Petit jeu : qui est le meilleur dev ?

Voici une fonction.

                
public function diviser(int $nb1, int $nb2): float
{
    try {
        echo ($nb1 / $nb2);
    } catch (DivisionByZeroError $e) {
        $this->logger->error($e);
        throw $e;
    }
}
                
                

Et on va juger les tests de deux dev.

Un développeur A.

                    

public function testDiviser()
{
    $this->assertEquals(2, $this->math->diviser(10, 5));
    $this->assertEquals(-2, $this->math->diviser(10, -5));
    $this->assertEquals(2, $this->math->diviser(-10, -5));
    $this->assertEquals(0, $this->math->diviser(0, 10));
}
                    
                

Maxime le développeur.

                    
public function testDiviser()
{
    $this->expectException(\Throwable::class);
    diviser(10, 0);
}
                    
                

Le meilleur est bien sûr :

Maxime (couverture de code à 100 % et code plus vite)

                        
declare(strict_types=1)

public function diviser(string $nb1, int $nb2): float
{
}
                        
                    

Conclusion

Je comprends pourquoi on cherche à quantifier.

Mais c'est loin d'être une bonne idée.

=> Ça pousse les mauvais à faire encore plus de merde.

Viser le 100 %.

Je ne suis pas à une contradiction près.

Visez pour VOUS le 100 %.

Pourquoi pas 99 % ?

• On doit se poser la question de savoir si oui ou non on le fait.
• 99 % coûte plus cher que 100 %.
• On risque beaucoup plus d'oublier.
• On doit passer par des phases de rattrapage.

Alors que 100 %

• Pas besoin de réfléchir : on le fait.
• À force, ça devient un réflexe.
• Et si en plus on cherche à comprendre : on apprend.

Oui mais...

Non, pas d'excuse.

Réfléchissez et ignorez...

Tous les outils qui appliquent des règles permettent d'ignorer.

Exemple phpunit...

                        
class Demonstration {
    /**
     * @codeCoverageIgnore
     */
    public function ignorerLaMethode() {
        $config = 'legacy_config';
        $this->connect($config);
    }

    public function ignorerDesLignes($valeur) {
        if ($valeur < 0) { return false; }

        // @codeCoverageIgnoreStart
        if (getenv('ENV') === 'dev') {var_dump($valeur);}
        // @codeCoverageIgnoreEnd
        return $valeur * 2;
    }
}
                        
                    

Doc PhpUnit

Un petit conseil :

• Un pro utilise un vrai IDE.
• Non, VSCode, c'est un jouet, pas un outil pour les pros.
• PHPStorm + des extensions
  • Php Inspections (EA Extended)
  • PHP Hammer
  • Symfony Plugin
  • PHP Annotations
  • Twig
• Soyez psychorigide sur les alertes.

Demander

Si l'entreprise vous demande de ne pas gêner les autres :

Alors c'est elle qui n'a rien compris.

Ce n'est pas parce que ça marche que ça marche.

???

Prenons un exemple

function maFonction($maVariable)
{
    if(!$maVariable) {
        return false;
    }

    return 10/$maVariable;
}

Il faut :

• Typer.
• Nommer.
• Éviter toute ambiguïté.
• Éviter la magie.
• Éviter de vouloir gagner du temps et des lignes de code.

SOLID

Retenez a minima :

• Single Responsability
• Dependency Inversion

KISS

keep it simple, stupid, « garde-le simple, idiot »

⚠️

Il est simple de faire compliqué, mais compliqué de faire simple.

Et si on a encore un peu de temps

• La veille...
• Les meetups... _{(+6 %)}
• Il n'y a pas qu'une seule solution.
• Toujours réfléchir et se mettre à la place des autres.