CarmaBlog

Xebia a récemment publié un livre blanc sur la qualité logicielle. Vraiment très intéressant et rapide à lire, je vous en recommande vivement sa lecture !

Ce document énonce les principales pistes d’amélioration de la qualité :

• Les méthodes agiles : SCRUM, Intégration continue;
• Pair-programming, TDD, etc;
• La lisibilité du code : respect des normes et des conventions, éviter une complexité trop élevée;
• Une bonne conception objet (design-patterns, code modulaire et réutilisable)

Tout ceci dans le but de faciliter la maintenabilité du logiciel (nouveaux développeurs dans l’équipe, nouvelles fonctionnalités à greffer).

Il sensibilise également aux risques qui peuvent survenir, notamment sur le piège de la sur-qualité (beaucoup d’effort pour finalement plus grand-chose).

Il évoque aussi des problématiques communes aux entreprises comme la réconciliation qualité/productivité. Le client veut tout et tout de suite, mais mieux vaut-il livrer rapidement un mauvais produit ou plutôt livrer un bon produit en un peu plus de temps ? Le “Time To Market” est toujours un grand défi à relever !

Voici l’article d’origine sur le blog de Xebia.

Avec Sébastien Roul, directeur technique de Netapsys, j’ai eu l’occasion de coanimer une présentation sur l’Intégration Continue devant une trentaine de professionnels et étudiants.

Il faut dire qu’après plus d’un an d’utilisation chez Netapsys Atlantique, l’Intégration Continue s’inscrit au coeur de notre métier avec une mise en place systématique sur l’ensemble de nos projets client.

Cette rencontre s’est déroulée dans le cadre des rencontres agiles à Nantes dans des locaux prêtés à l’occasion par l’école SUPINFO.

L’intérêt de cette double intervention a permis de présenter ma vision de développeur avec une utilisation quotidienne, mais aussi la vision de chef de projet avec Sébastien.

L’intégration continue n’est pas seulement l’installation d’un serveur avec quelques outils appropriés, c’est vraiment un état d’esprit qui doit vivre au sein de toute l’équipe…

Voici les slides de la présentation.

Je vous invite également à lire mon précédent article sur l’intégration continue avec un dossier complet.

Je profite de mon dernier article sur l’Intégration Continue pour vous présenter une nouvelle bonne pratique de l’eXtreme Programming (XP): Test-driven Development (TDD) ou Développement Dirigé par les Tests. En fait, l’Intégration Continue est fortement liée à ce concept. Pour en savoir plus sur les bonnes pratiques de l’XP, vous pouvez cliquer sur le logo juste ci-dessous.

Les tests représentent une partie critique dans le développement de logiciels. TDD est une technique, où les tests sont écrits progressivement, dès le début du projet, et surtout avant l’implémentation du code. Pour aider le développeur dans cette tâche, des outils d’automatisation de tests existent. Par exemple, la série XUnit est une des plus populaires.

TDD en quelques mots

D’abord, le développeur imagine et écrit un test (un test qui va échouer car le code qu’il teste n’a pas encore été écrit). Ensuite, il écrit le code dans le but de passer (réussir) le test (juste le code qu’il faut, pas plus!). Finalement, le développeur ré-arrange son code (cette étape s’appelle le “refactoring”), et il s’assure que le test passe toujours. Refactoriser le code est une étape importante de TDD, elle vise à améliorer le code qu’on a écrit tout en gardant les mêmes fonctionnalités. Par exemple, cela peut être une suppression de variable inutilisée, une diminution de la duplication du code, un ajout de commentaire, une amélioration de sa lisibilité, etc.

Ce cycle est répété plusieurs fois par heure, chaque cycle concernant une fonctionnalité très précise du logiciel.

Généralement, les développeurs modélisent, codent, et à la fin seulement, ils testent. L’inversion entre la première et la dernière étape est très déconcertante, mais cela ne veut pas dire pour autant que c’est une mauvaise chose…

Bien au contraire, les avantages sont multiples. Pour ne citer que les plus évidents, le taux de couverture du code par les tests se rapproche du 100%, la qualité du code s’en trouve améliorée, la découverte des bogues est faite en amont, les développeurs ont une meilleure confiance dans leur application (ils sont certains que ce qu’ils ont codé est fonctionnel et a été pleinement testé). Rappelons, encore une fois, que plus un bogue est découvert tôt dans le projet, moins il coûtera cher.

S’agissant que d’une introduction, mon article s’arrête ici. Mais, je vous invite à vous renseigner davantage sur la toile si le concept vous intéresse ou vous intrigue.