Des retours des formés qui font plaisir !

Ca y est, je peux enfin me poser quelques jours, avant de repartir à donner des formations. Cinq mois où l’on donne des formations aux quatre coins de la France, ça donne quoi ?
Faisons ensemble un tour des retours des stagiaires qui ont pu suivre mes formations.

(suite…)

Découvrons ensemble une méthode pour amener un code de qualité. Car bien coder, c’est bien, mais coder sans penser au reste de l’application, ça amène des risques forts pour tout le projet, le site web que l’on développe. Cette méthode, la méthode C2T (Code, Test, Test tout), amène trois étapes pour créer du code et une application de qualité.

Nous verrons d’ailleurs que l’on pourra un peu modifier son appellation en fin de cet article.

Code, en cherchant la qualité

La méthode C2T commence par le code, comme pour toute application, site web, ou logiciel de gestion.

Lorsque l’on code, il faut toujours chercher à créer un code de qualité.

Chercher à appliquer des principes de bases, tels que :

Des approches agiles, par exemple XP (eXtreme Programing) ont cherché à renforcer ces principes jusqu’à « l’extrême », car essentiels pour avoir un code, un projet de qualité.

Teste ton code

C’est bien beau de créer un code qualité, mais s’il n’est pas testé, on aura des bugs en production.
Et toute la qualité pensée n’aura servi à rien.

C’est ici tout l’équilibre entre un code maintenable, de bonne qualité, mais aussi testable, et vérifiable.

Il ne suffit pas d’être le-la meillleur-e codeur-euse à créer (pisser) des milliers de lignes de code. Si on oublie de vérifier son code, régulièrement, on est vite confronté à des bugs d’exécution … bien souvent rudimentaires.

Petit clin d’oeil de commit strip

 

Donc après chaque fonction écrite, voire même partie de code, on teste :

Teste tout, pour une qualité dans son code

Et puis, une fois que l’on a fini une fonctionnalité, on va chercher à la tester dans son environnement complet : l’application.

Ainsi, on relance tous les tests automatisés (s’il y en a), on demande aux testeurs de vérifier toutes les fonctionnalités.
Et surtout, ô surtout, on vérifie soit même avant de l’envoyer aux testeurs.

Le cahier de recette ne doit pas, par exemple, réservés aux recetteurs.
C’est un outil qui doit être partagés entre :

 

L’astuce du concrétiseur : Le mindmap des dépendances de fonctionnalités

Pour aider les développeurs, et même les testeurs, recetteurs, il peut être intéressant de mettre en place un mindmap (une carte heuristique) des fonctionnalités, et de leurs dépendances.

Wordpress - Outil d'administration
Exemple de début de minmap des dépendances de fonctionnalités

 

Ainsi, si on modifie la fonctionnalité de création d’article, nous irons tout de suite tester la modification d’article.

Note : la granularité peut être plus fine, au besoin, et représenter ds modules qui sont utilisés par plusieurs fonctionnalités.

 


Et vous, comment faîtes-vous pour assurer la qualité de vos logiciels, de vos applications ?