Blog ENI : Toute la veille numérique !
💥 Un livre PAPIER acheté
= La version EN LIGNE offerte pendant 1 an !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Software Craftsmanship
  3. Savoir
Extrait - Software Craftsmanship L'art du code et de l'agilité technique en entreprise
Extraits du livre
Software Craftsmanship L'art du code et de l'agilité technique en entreprise
1 avis
Revenir à la page d'achat du livre

Savoir-faire

Introduction

« The problem is not the amount of unexpected changes in a software project; the problem is our inability to cope with them. »- The software craftsman

Bienvenue dans la deuxième partie. Vous entrez dans le second tunnel de l’aventure, pour vous initier à différentes techniques d’assurance qualité, qui vous aideront à maîtriser les besoins d’évolution logicielle. Et cela en complémentarité avec les boucles de feedback identifiées en première partie. Derrière ces techniques existent les éléments nécessaires pour produire du code et du produit de qualité.

Nous mettrons ainsi l’accent sur l’importance des tests dans la réalisation des solutions. La différence entre un produit A et un produit B, à fonctionnalités égales, est la qualité, tant perceptible que non perceptible par le client final.

Ce principe se retrouve chez les artisans horlogers. Deux montres, d’apparences identiques, n’auraient pas forcément le même prix. En effet, elles ne seraient pas architecturées, montées et testées de la même façon. En développement informatique, le Test avec un grand T est le garant d’un produit de qualité. 

Découvrons-les !

images/02DP00.png

Tant qu’à faire quelque chose, autant...

TDD, au-delà du DD

« Quality is not expensive. The lack of skills is what makes well-crafted software expensive. TDD doesn’t slow developers down. Typing is not a bottleneck. Learning and mastering a new skill, practice, or technology is. » - Sandro Mancuso (The Software Craftsman: Professionalism, Pragmatism, Pride - série Uncle Bob)

Le TDD (Test Driven Development, développement et documentation par les tests) est une technique de développement où les tests sont moteurs du design applicatif. Contrairement à ce que l’on peut parfois entendre, il ne se résume pas à la réalisation de tests unitaires ou à l’utilisation de JUnit dans le cadre de projets Java. Mais en quoi cette distinction nous intéresse-t-elle en tant qu’aspirants craft ?

Rappelons-nous quelques valeurs du manifeste, à savoir la capacité à réaliser des logiciels bien conçus et l’apport constant de valeur. Ces deux aspects se placent sous couvert d’un apport constant de qualité en matière de design et en matière de valeur produit, afin de répondre pertinemment aux attentes des utilisateurs. Le TDD y contribue !

Avant de plonger dans différents étonnements structurant le sujet, il est opportun de parcourir les invariants et principes clés du TDD.

  • Test First : on rencontre souvent des équipes ou des entreprises qui se vantent de faire du TDD. Les tests y sont souvent rédigés, dans le cadre des projets, pour valider du code déjà produit et non pour produire du code. Soyons justes, quand on fait du TDD, on écrit le test en premier, en phase avec une attente produit, et ce n’est qu’ensuite que l’on écrit l’algorithme permettant d’y répondre. L’un des bénéfices du Test First, c’est qu’il aide à améliorer et approfondir en amont notre compréhension du besoin métier en traduisant celui-ci par des intentions de test.

  • KISS and YAGNI (YAGNI - You Are not Gonna Need It, évitez l’over-architecture et l’utilisation de concepts et de code dont vous n’aurez pas forcément besoin) : d’un côté, la simplicité est l’un des facteurs clés du TDD. Plus notre code est simple...

BDD, encore du DD

« BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters. » - Dan North

La communication est un facteur clé dans la réussite de tout projet informatique. Toute équipe, bien que dotée de compétences techniques, peut se retrouver en situation d’échec sur un projet à cause d’une mauvaise gestion de la communication. À l’opposé, une bonne communication entre les différents intervenants d’un projet offre plus aisément des opportunités de succès. Le BDD (Behavior Driven Development) est un dérivé du TDD. Ce process de développement tend à améliorer la communication et les attentes entre techniques (maîtrise d’œuvre) et non techniques (maîtrise d’ouvrage).

images/02DP05.png

1. Les origines [source]

  • 2003 : agiledox est l’ancêtre du BDD, il a été écrit par Chris Stevenson avec comme objet la génération de documentation technique à partir des tests unitaires.

  • 2004 : JBehave, première release par Dan North.

  • 2006 : popularisation de la syntaxe Gerkhin given-when-then par Dan North, en collaboration avec Chris Matts, pour élargir l’adoption du BDD aux analystes fonctionnels ; on parle désormais d’ubiquitous language.

  • 2006-2009 : apparition de nouveaux outils révélant un réel investissement de la communauté open source sur le BDD, RSpec (context(), describe(), it()) en Ruby initié par Steven Baker avec la participation de Dan North et Aslak Hellesøy, puis l’émergence de Cucumber (Aslak Hellesøy), GivWenZen ou encore Toast-TK.

Le BDD améliore la collaboration entre l’équipe de développement et les équipes métiers grâce à la combinaison de principes issus du TDD et du DDD. Il permet, sur la base d’un DSL (Domain Specific Language), d’exprimer des cas de tests en langage naturel et qui reflète le comportement attendu par le business.

Mais pourquoi le BDD ? Il se trouve que Dan North, pionnier en la matière, avait relevé...

Agile Testing

images/02DP11.png

Exploration du domaine de l’Agile Testing

La qualité est toujours attendue par les clients. Même s’ils n’en parlent pas ou qu’ils expriment expressément la volonté d’aller plus vite et de faire moins cher au détriment des phases de tests, au fond d’eux, ils s’attendent toujours, quand même, à avoir un produit de qualité correspondant à leurs attentes.

Les méthodologies agiles s’imposent, de plus en plus, comme un standard pour la réalisation de logiciels. Elles viennent remplacer les rituels séquentiels, à l’image du cycle en V. Dans ce dernier, la qualité fait l’objet d’une phase s’inscrivant en fin de cycle, pour valider la mise en production du logiciel. Pendant cette phase, il est courant de rencontrer des équipes d’assurance qualité dites fonctionnelles. Elles y exécutent pendant plusieurs semaines, tant des tests manuels que des tests automatisés. Voici quelques inconvénients de cette approche :

  • déresponsabilisation des entités, en dehors de l’équipe d’assurance qualité, vis-à-vis de cette phase clé ;

  • durée des cycles de vérification et de validation ;

  • temps long dans le cycle de développement avant de pouvoir avoir un feedback sur la qualité du logiciel ;

  • rigidité et difficulté à modifier, remettre en question le périmètre des batteries de tests à effectuer.

Dans le monde Agile, il est crucial de tester le plus tôt possible et le plus souvent possible. Il est important de s’assurer de pouvoir capturer et prioriser les besoins des utilisateurs et de les évaluer tout au long du cycle de développement. Une des clés de réussite des projets agiles est d’éviter de concentrer les activités de test au dernier moment, avec une validation ultime pour la mise en production. L’Agile Testing est le domaine qui englobe l’espace de méthodes, rituels et outils et qui instruit correctement la pratique de test au sein des équipes agiles. Les tests n’y font pas l’objet d’une phase discrète. Ils ne sont plus sanctuarisés dans des plans de tests préécrits, rigides et qui font office...

Performance et sécurité

« Anything that can go wrong will go wrong. » - Murphy’s law

La sécurité et la performance font partie de ces aspects applicatifs que l’on catégorise par défaut comme étant des besoins non fonctionnels, pour la simple et bonne raison qu’elles sont souvent considérées comme des notions implicites. Les clients, les utilisateurs finaux, partent du postulat qu’il n’y a pas lieu de spécifier ce qui est évident, ce qui semble être du bon sens, à savoir bénéficier d’une application sécurisée et performante. Et cela au même titre qu’il n’y a pas besoin de préciser que l’on souhaite avoir un système de qualité. Ce sont là des aspects qui s’inscrivent dans le périmètre des tests exploratoires menés dans le cadre de l’Agile Testing. Ils sont non négociables !

L’expérience utilisateur en dépend. Il n’est ni concevable ni acceptable d’offrir une UX moindre, celle où l’utilisateur ne bénéficierait pas du bon niveau de protection de ses données personnelles, d’une intégrité fonctionnelle et de performances raisonnables. Quelque part, la relation qui s’établit entre un utilisateur et une application se révèle être de l’ordre de la relation de confiance.

Dans le cas du Craftsmanship, nous participons activement et proactivement à la création de cette relation de confiance. Sa pérennisation est nécessaire pour la construction de partenariats productifs avec nos clients. Je vous renvoie particulièrement à la quatrième et dernière valeur du Manifesto of Software Craftsmanship.

« Not only customer collaboration, but also productive partnerships. » - 4th craftsmanship value

En tant qu’aspirant craft, vous devez veiller par défaut à la réalisation de solutions sécurisées, performantes et maintenables. En gardant le futur à l’esprit, vous devez intégrer de telles préoccupations dans vos rituels, allant du design jusqu’au monitoring de l’application en production. C’est une préoccupation continue...

Synthèse et exercices

1. Takeaways

1)

Le TDD ne se résume pas à la production de tests unitaires, c’est un rituel indissociable du savoir-faire craft.

2)

Le TDD est une technique de développement où les tests sont moteurs du design applicatif.

3)

Le TDD est indispensable pour tout craft aspirant à la création de logiciels bien conçus et à valeur ajoutée.

4)

Commencer par créer un test, le faire échouer, écrire le minimum de code pour qu’il passe. Ensuite, rentrer dans la boucle de refactoring.

5)

Le refactoring vise à améliorer le design d’un code déjà couvert par au moins un test unitaire. Il permet aussi de supprimer des codes smells, de réduire la dette technique, tout en bénéficiant de la protection du harnais de test.

6)

En tant que craft, vous avez un devoir de pédagogie, un devoir d’empathie, c’est de votre responsabilité de travailler dans une configuration qui vous est favorable, de sensibiliser vos interlocuteurs à l’importance de votre méthodologie, de la valeur que ça leur apporte. Faire des tests unitaires, c’est se donner la chance de faire les choses bien du premier coup, et d’être ainsi plutôt dans la prévention que dans la guérison.

7)

Le TDD offre un harnais de test qui sert de documentation pour le Quoi du code, documentation qui sert de référence et d’assurance.

8)

Le BDD (Behavior Driven Development) est un dérivé du TDD. Ce process de développement tend à améliorer la communication et les attentes entre techniques (maîtrise d’œuvre) et non-techniques (maîtrise d’ouvrage).

9)

Le BDD est une méthodologie de développement logiciel qui s’appuie sur la spécification par l’exemple. Elle engage les développeurs, les analystes fonctionnels et les qualiticiens autour d’une compréhension partagée de l’expérience attendue par l’utilisateur.

10)

Le format semi-formel rend les spécifications exécutables. On obtient, itération après itération, un harnais de test de régression. Sur un constat d’erreur d’exécution, il est facile d’analyser la situation et de faire le rapprochement...