5 étapes pour commencer à gérer sa qualité logicielle

Parvenir à piloter efficacement la qualité de ses projets logiciels ne se fait pas en un jour. Mais tout comme Rome, il y a un début à tout. Et dans cette aventure, bien démarrer n’est pourtant pas l’étape la plus difficile. Que vous soyez en cours de projet ou à sa phase d’amorçage, nous vous proposons 5 actions à mener qui, selon moi, sont essentielles pour constituer un environnement de développement support à la gestion de la qualité.

1) Définir un référentiel de bonnes pratiques de code

On le sait, un code uniforme respectant des standards de codage est plus facile à maintenir et plus agréable à lire pour les équipes de développement. Il est donc primordial de définir un référentiel commun sur l’utilisation des langages de programmation dans vos équipes. Conventions, mise en forme, constructions, appels d’API, tout doit y passer. Cela peut paraître un dur labeur, mais heureusement pour nous, il existe les linters : ces outils définissent un ensemble de règles, généralement configurables, pour un langage de programmation donné. Nous vous conseillons d’adopter un linter par langage utilisé, et d’utiliser pour commencer une configuration par défaut. Vous pourrez par la suite vous l’approprier pour définir votre propre référentiel. Utilisez-le sur votre code afin de voir si le résultat vous convient.

En plus des linters, nous conseillons de documenter les conventions qui ne peuvent être automatiquement vérifiées par les linters, comme par l’exemple l’utilisation d’un framework particulier. Cela peut prendre la forme d’un wiki collaboratif alimenté par les équipes, et qui est régulièrement discuté et mis à jour. Et en complément de la configuration du linter, cela constitue un réel support pour vos équipes. Rassurez-vous : il y a peu de chances que ces dernières vivent la mise en place de bonnes pratiques comme une contrainte. Au contraire, cela donne le sentiment qu’on a envie de faire les choses proprement. Gardez aussi en tête que ce support sera fort utile lorsque de nouvelles personnes rejoindront votre équipe.

2) Adopter une gestion décentralisée du code source

Le code source est généralement stocké et versionné dans un dépôt géré par des outils tel que Git, SVN ou encore Mercurial. Votre gestionnaire de code source définit la façon dont vos équipes s’organisent pour contribuer au projet : peuvent-elles travailler simultanément sur un même fichier ? Peuvent-elles valider leur travail sans impacter celui des autres ? Comment faire en sorte que chaque modification soit validée par un membre de l’équipe ?

Des systèmes tels que Git ou Mercurial permettent aux équipes de collaborer facilement de façon décentralisée. Chaque personne contribue sur sa propre copie du dépôt de code, y effectue des commits et peut dès qu’elle le souhaite pousser ses modifications sur le serveur. L’utilisation des branches par Git et Mercurial permet d’isoler facilement les changements apportés par chaque personne et d’utiliser les fusions pour les intégrer dans la branche de développement principale. En évitant un système décentralisé, on ne limite pas la productivité des équipes qui peuvent ainsi avancer sur leurs tâches respectives.

De plus, l’utilisation des pull requests, via des outils tels que GitHub ou Bitbucket, permet d’observer finement et facilement les modifications apportées par une personne sur le code afin de les fusionner sur une branche de développement. Cette pull request, en complément des linters, permet de mettre en place des revues de code entre les différentes personnes de l’équipe. La revue de code est vivement conseillée pour maintenir un haut niveau de qualité de code. C’est encore le meilleur moyen de diffuser et d’échanger sur les bonnes pratiques. 

3) Documenter l’architecture du code

Un grand principe du Clean Code est d’éviter les commentaires parce-que-les-noms-des-éléments-doivent-parler-d’eux-mêmes. Même en respectant cela, ce n’est pas suffisant pour maintenir une vision plus macro du logiciel. Imaginez que vous devez présenter à quelqu’un l’organisation d’un livre extrêmement bien écrit de plusieurs centaines de pages. Ne trouveriez-vous pas cela plus facile à faire si on vous met à disposition un plan détaillé ou un résumé de quelques pages ? Cette vision macro doit permettre de comprendre comment l’architecture est découpée, quels sont les principaux composants et leurs sous-composants, comment le tout est orchestré, qui appelle qui, … Nous recommandons vivement de mettre en place une documentation sous forme de wiki collaboratif et d’y expliquer les concepts-clés du code, schématiser les composants et leurs dépendances, décrire les commandes pour jouer les tests, indiquer comment paramétrer son IDE…

Cela peut paraître long, difficile à maintenir, mais il est important de garder en tête qu’écrire de la documentation, tout comme écrire des tests, fait partie intégrante du quotidien d’un·e développeur. Vous y trouverez des bénéfices le jour où vous vous replongerez dans une partie du logiciel non modifiée depuis plusieurs mois, ou encore si vous devez expliquer à quelqu’un l’architecture de votre logiciel. La documentation doit faire partie selon nous de la Definition of Done d’une tâche, là où on considère trop souvent que seule l’implémentation d’un code suffit.

Un code avec une documentation à jour sera plus facile à maintenir et constitue un outil de communication efficace pour vos équipes. A l’inverse, sans documentation, vous risquez de perdre du temps à comprendre et expliquer votre code, et cela sera toujours du temps en moins consacré à d’autres activités.

4) Mettre en place des tests automatisés

Ecrire des tests permet de vérifier le comportement attendu par votre code. Quelle que soit l’approche adoptée (TDD, BDD…), il est vivement recommandé de maintenir une suite de tests dans vos logiciels. Plus vous écrivez du code sans tests, plus le risque qu’il contienne des bugs augmente. Certes écrire des tests ne peut garantir le risque zéro de bugs. Mais lorsqu’on développe une nouvelle fonctionnalité, il faut admettre en amont qu’il est tout à fait normal de consacrer au moins 50 % du temps de développement à la rédaction de tests.

Il faudra commencer par définir un framework de tests selon votre langage (ex : JUnit pour Java), écrire vos premiers tests unitaires voire d’intégration. Une fois cela mis en place, vous serez plus serein sur les prochaines modifications que vous apporterez au code. Ces tests seront les gardiens de la non-régression. Utiliser un framework de test vous permet surtout d’automatiser l’exécution de votre suite de tests. Une simple exécution en ligne de commande sera suffisante pour voir si tous vos tests sont au vert !

5) Déployer une intégration continue

Aujourd’hui, mener un projet sans intégration continue, c’est un peu comme creuser un trou sans pelle : on peut y arriver, mais le résultat sera assez médiocre. L‘intégration continue, c’est surtout l’automatisation de toute la chaîne de construction d’un logiciel : compilation, exécution des tests, calcul de métriques, packaging puis archivage sur un référentiel. En pratique, ce sont des outils tels que Jenkins qui font le travail pour vous. Vous définissez vos tâches, ce qui les déclenche et dans quel ordre elles s’exécutent. Vous pouvez ainsi lancer le processus toutes les heures ou après chaque commit sur votre dépôt Git. A chaque déclenchement, toutes les étapes s’enchaînent et ont deux issues possibles : succès ou échec. En cas d’échec, toute l’opération s’arrête et vous alerte qu’un problème a eu lieu. Tout cela n’est-il pas rassurant au moment de livrer votre logiciel ?

Finalement, l’intégration continue permet surtout :

• d’avoir un processus automatique bien défini sur la façon de construire le logiciel. On cherche ainsi à diminuer le risque d’erreurs “humaines” liées à une construction manuelle du logicielle.
• de diminuer le risque d’erreurs et de régressions. En effet, ce processus continu permet de vous notifier, par exemple, que vos tests ne passent plus suite au dernier incrément de code.
• de générer des mesures sur la qualité de votre code, et de produire ainsi une matière première essentielle pour piloter la qualité de vos projets.

Conclusion

Vous l’avez certainement compris, des bonnes pratiques et des outils de mesure constituent un terreau fertil pour bâtir une stratégie efficace de gestion de la qualité logicielle. D’autres façons de débuter existent, à vous de déterminer lesquelles sont les plus pertinentes pour votre organisation. Votre prochain défi ? Intégrer ces bonnes pratiques dans votre culture d’entreprise, adapter vos process et votre organisation pour faire face à cet enjeu de la qualité.