1. #DevoxxFR
Sensibilisation aux bonnes pratiques techniques du
Software Craftsmanship
Lego® à la rescousse !
Isabelle Blasquez @iblasquez
Alice Barralon @a_barralon
1
2. #DevoxxFR
La puissance des LEGO®
915 103 765
combinaisons possibles
2
Le jeu est comme un engrais pour la croissance du cerveau.
Il est fou de ne pas l’utiliser. --Stuart Brown
Il faut jouer pour devenir sérieux. --Aristote
3. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
Version originale :
About the LEGO technical practices exercises : http://www.gargoylesoftware.com/ex
Adapté d’une idée originale de
4. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
Version originale :
About the LEGO technical practices exercises : http://www.gargoylesoftware.com/ex
Repris et traduit par
9. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
Bonnes Pratiques : 2 principes indispensables
KISS
Keep It Simple Stupid
YAGNI
You Aren’t Gonna Need It
10. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
Une livraison KISS pour notre problème …
Inspiré de by Kelly Johnson et http://www.slideshare.net/theojungeblut/20101010-lego-for-software-engineers
12. #DevoxxFR
Quid du programme informatique parfait ?
127.0.0.1:6363[2]> Quand nous créons un nouveau projet, nous commençons avec un programme parfait
(integer) 1
127.0.0.1:6363[2]>
127.0.0.1:6363[2]> A chaque ajout de code, nous nous éloignons de cet idéal
(integer) 1
127.0.0.1:6363[2]> Garder un programme aussi simple et petit que possible…
(integer) 1
12
Extrait du site : http://www.topito.com/top-constructions-lego
En savoir plus sur les oeuvres de Nathan Sawaya : http://www.brickartist.com/et http://www.nathansawaya.com/
13. #DevoxxFR
eXtreme
Programming
1. Tous les tests passent
2. Révéler l’intention du
code
3. DRY : Don’t Repeat
Yourself
4. Le plus petit nombre
d’éléments
13
Extrait : http://c2.com/cgi/wiki?XpSimplicityRules
A lire : http://martinfowler.com/bliki/BeckDesignRules.html
et https://leanpub.com/4rulesofsimpledesign
A voir : Extreme Programming 20 years later by Kent Beck : https://www.youtube.com/watch?v=cGuTmOUdFbo
“I’m not a grat programmer, I’m juste agood programmer with
great habits”
–Kent Beck
14. #DevoxxFR
Test Driven Development (TDD) : à la Rescousse !
14
Descriptif original de l’atelier disponible sur : http://www.gargoylesoftware.com/ex/lego_tdd
16. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
Refactoring : Définition
« Un refactoring (remaniement) consiste à changer
la structure interne d’un logiciel
sans en changer son comportement observable »
-- M. Fowler
« Clean code that works »
-- Ron Jeffries
« Du code non testé est du code qui ne fonctionne pas »
-- Kent Beck
Pas de refactoring sans test !!!
17. #DevoxxFR
TDD : Red > Green > Refactor
> Existe t’il une personne dans le programme ?
17
18. #DevoxxFR
TDD : Red > Green > Refactor
> Existe t’il une personne dans le programme ?
> Existe t’il une maison dans le programme ?
18
19. #DevoxxFR
TDD : Red > Green > Refactor
> Existe t’il une personne dans le programme ?
> Existe t’il une maison dans le programme ?
> Est-il vrai que la maison est plus haute que
la personne ?
19
20. #DevoxxFR
TDD : Red > Green > Refactor
> Existe t’il une personne dans le programme ?
> Existe t’il une maison dans le programme ?
> Est-il vrai que la maison est plus haute que
la personne ?
> La maison est plus large que la personne ?
20
21. #DevoxxFR
TDD : Red > Green > Refactor
> Existe t’il une personne dans le programme ?
> Existe t’il une maison dans le programme ?
> Est-il vrai que la maison est plus haute que
la personne ?
> La maison est plus large que la personne ?
> La personne peut entrer dans la maison ?
21
23. #DevoxxFR
Refactoring: pour minimiser la dette technique !
23
Descriptif original de l’atelier disponible sur : http://www.gargoylesoftware.com/ex/technical_debt
29. #DevoxxFR
Refactoring interdit !
> 2 murs connectés
> une fenêtre sur un mur
> entièrement fermée
> un toit en pente
> une cheminée
> une porte au RDC
29
30. #DevoxxFR
Refactoring interdit !
> 2 murs connectés
> une fenêtre sur un mur
> entièrement fermée
> un toit en pente
> une cheminée
> une porte au RDC
> une fenêtre sur un second mur
30
31. #DevoxxFR
Refactoring interdit !
> 2 murs connectés
> une fenêtre sur un mur
> entièrement fermée
> un toit en pente
> une cheminée
> une porte au RDC
> une fenêtre sur un second mur
> Les toits en pente ne se vendent
plus: un toit plat
31
38. #DevoxxFR
Refactoring autorisé !
> 2 murs connectés
> une fenêtre sur un mur
> entièrement fermée
> un toit en pente
> une cheminée
> une porte au RDC
38
39. #DevoxxFR
Refactoring autorisé !
> 2 murs connectés
> une fenêtre sur un mur
> entièrement fermée
> un toit en pente
> une cheminée
> une porte au RDC
> une fenêtre sur un second mur
39
40. #DevoxxFR
Refactoring autorisé !
> 2 murs connectés
> une fenêtre sur un mur
> entièrement fermée
> un toit en pente
> une cheminée
> une porte au RDC
> une fenêtre sur un second mur
> Les toits en pente ne se vendent
plus: un toit plat
40
42. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
Bonne Pratique : Refactoring
& Dette technique
Les étapes de refactoring permettent au
développeur de travailler
sur un code propre (clean code) et
de minimiser la dette technique
43. #DevoxxFR
A l’image du potier qui
travaille son argile en
continu, le développeur
travaille son code en
permanence.
-- Benoit Gantaume
43
44. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
Le copilote écrit un nouveau test,
Le pilote construit
en LEGO®
Refactor
Rôle pilote-
copilote
TDD en pair-building pour cet exercice …
45. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
Bonne Pratique : Pair Programming
A partir de
maintenant, vous
travaillerez
en binôme
46. #DevoxxFR
La propreté du code, une responsabilité collective
46
Descriptif original de l’atelier disponible sur : http://www.gargoylesoftware.com/ex/technical_debt
49. #DevoxxFR
Prêt pour le grand plongeon en équipe ?
49
Descriptif original de l’atelier disponible sur : http://www.gargoylesoftware.com/ex/technical_debt
50. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
Une équipe de 6 personnes
en pair-building
sur une même table
Une équipe
=
une entreprise
avec une super idée !
Construire en Equipe …
Une grande construction composée de
petites constructions indépendantes
(zoo, un aéroport, un parc d’attraction…)
52. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
The act of writing a unit test
is more an act of design than of verification.
It is also more an act of documentation than of verification
(Robert. C. Martin)
TDD : Une pratique de conception ?
Le refactoring contribue à travers tous les cycles du TDD
à l’obtention d’une conception simple et évolutive appelée conception émergente
Test Driven
Developpement
Design
56. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
5 équipes
1 projet commun pour le groupe …
1 équipe/table
En vacances dans une destination
exotique, nous souhaitons envoyer
des cadeaux
à nos proches par voie maritime …
57. #DevoxxFR
Construire un système d’acheminement de cadeaux
> Equipe #1 : construire les cadeaux à ramener
> Equipe #2 : construire le conteneur qui contiendra les cadeaux
> Equipe #3 : construire le camion qui contiendra le conteneur
> Equipe #4 : construire la grue qui permettra de soulever le
conteneur du camion pour le déposer sur le navire
> Equipe #5 : construire le navire qui acheminera le conteneur
57
58. #DevoxxFR
Est-ce que les cadeaux rentrent dans le conteneur ?
Est-ce que la grue est adaptée à la taille du conteneur ?
Est-ce que le conteneur est adapté à la taille du camion ?
Que dire dur le navire ?
58
59. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
Rétrospective
Découvrir ce qu’on a fait de bien
Comprendre ce qui n’a pas marché
Trouver des moyens pour s’améliorer
Échanger, communiquer
Qu’est-ce qui doit être
amélioré ?
Qu’est-ce qui a bien
fonctionné et qu’il faut
garder ?
60. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
1 minute de planification
(Ne pas toucher aux briques !)
3 minutes de construction
Itération 2
61. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
Intégration & Rétrospective
Quels composants
ont été livrés ?
Attention !!!
Si les cadeaux n’arrivent pas jusque dans le navire,
votre livraison n’apporte aucune valeur métier …
62. #DevoxxFR
Qu’est-ce qui vous a surpris ?
Comment s’organiser pour offrir des cadeaux au plut tôt ?
(livrer au plus tôt de bout en bout tous les composants).
Qu’avez-vous mis en place pour vous améliorer ?
62
64. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
Combien d’itérations pour arriver
à ces œuvres d’art ?
En savoir plus sur l’exposition Art of the Brick :
http://www.parentsatoutprix.fr/the-art-of-the-brick-avis/ Photo prise à
65. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
Qu’avez-vous ressenti ?
Bilan & Rétrospective
Qu’avez-vous appris ?
Que mettrez-vous en application
dès lundi ?
67. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
WebOGraphie (1/2)
Descriptif original des ateliers “About the LEGO® technical practices exercises” :
http://www.gargoylesoftware.com/ex
Vidéo : Enregistrement d’un atelier : TDD and Refactoring with LEGO by Bryan Beecham (2014)
https://www.infoq.com/presentations/tdd-lego
Transparents : TDD and Refactoring with LEGO at Agile2013 :
http://fr.slideshare.net/BillyGarnet/td-dand-refactoringwithlegoagile2013-25143447
http://fr.slideshare.net/BillyGarnet/tdd-and-refactoring-with-lego
Video teasing Lego TDD & Refactoring ATT :
https://www.youtube.com/watch?v=w7oupm_2KH0
Photos: https://flic.kr/s/aHsjPgKJAk
sur le compte de https://www.flickr.com/photos/livingjuicy (album NYC Scrum Users Group Dec. 2013)
68. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
WebOGraphie (2/2)
Articles :
Using Lego to Teach Technical Practices (Article original) :
https://www.infoq.com/news/2016/05/lego-teach-technical
Des Lego pour Apprendre les Pratiques Techniques (version française) :
https://www.infoq.com/fr/news/2016/06/lego-teach-technical
Egalement :
Intro to Refactoring with LEGOs : http://agilecomplexificationinverter.blogspot.fr/2013/12/intro-to-refactoring-with-legos.html
http://www.boost.co.nz/blog/2013/11/what-does-lego-and-building-high-quality-software-have-in-common/
The ROI of Refactoring: Lego vs. Play-Doh :
http://fr.slideshare.net/NeilGreen1/the-roi-of-refactoring-lego-vs-playdoh
69. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
En savoir plus sur le Software Craftsmanship
techtrends.xebia.fr
https://leanpub.com/socra
https://pragprog.com/book/tpp/t
he-pragmatic-programmer
http://www.octo.com/fr/livres-blancs
70. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
A méditer …
Article complet disponible sur : http://gb-prod.fr/2016/06/12/artisan-developpeur.html
71. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
Article complet disponible sur : https://medium.com/alebaffa-blog/how-can-you-say-youre-a-software-
crafts-wo-man-48ebc055ba9d#.byqyxzdjx
Et aussi …
72. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
Une brique : le pouvoir de la métaphore
au service de la simplicité
Extrait : http://piwee.net/1-affiches-minimalistes-brique-lego-030516
Par participant :
→ une sachet de LEGO : uniquement des briques : pas de mini-figurine ou autre qui pourrait donner une indication sur la taille des fenêtres et porte. Il ne faut pas influencer les participants dans leur créativité
→ carton rouge et vert
→ index card (fiches sous forme de post-it ou petites feuilles de papier)
KISS, est une ligne directrice de conception qui préconise la simplicité dans la conception et que toute complexité non indispensable devrait être évitée dans toute la mesure du possible.
Faire simple au niveau de la conception : le pouvoir de la métaphore du légo. On peut facilement étendre ou maintenir.
J’ai une maison : cout minimal et design simple !
YAGNI : pas d’ajouter de fonctionnalité (pas d’over analyzing)
YAGNI like a DRY KISS
YAGNI : vous n'en aurez pas besoin est un principe d'extreme programming qui déclare que les programmeurs ne devraient pas ajouter de fonctionnalité à un logiciel tant que celle-ci n'est pas absolument nécessaire
YAGNI (You aint gona need it) refers to over analyzing and implementing things that may or may not be needed.
KISS (Keep it simple stupid) refers to the fact that easy systems are easier to manage. Keeping things simple is not nesseserily less work (like YAGNI is) since it requires more knowlege to implement. They are sometimes similar but grow from different needs.
Une brique suffit pour représenter la maison : on joue ainsi que la métaphore !
On ne nous a pas encore demandé une table et un arbre…
Peut-être que notre maison n’aura pas besoin de fenêtre => entrepot : faire juste ce qui est demandé !
Nettoyez votre espace de travail
Espace vide = programme parfait
Qu’est ce qu’un programme parfait ? >> NOTER SUR PAPER BOARD LES REPONSES
Satisfait toutes les exigences => Tout à fait : il n’y a aucune exigence à ce moment là ;-)
http://www.gargoylesoftware.com/ex/lego_simplicity
Nettoyer votre espace de travail en regroupant tous les LEGO® sur le côté.
Quand noud créons un nouveau projet, nous commençons avec un programme parfait et à chaque fois que nous ajoutons quelque chose de nouveau,
nous nous éloignons de l’idéal.
Nous allons souhaitons garder le logiciel aussi simple et petit que possible tout en restant au plus proche de l’ideal.
Parce qu’un code doit être lisible et facilement maintenable ….
TDD => 3 point sur les 4
Le point n°3 : le refactoring ….
Tests Pass
2. Expresses Intent
3. No Duplication (DRY)
4. Small : limiter la complexité, les codes smells…
1. Le code est doté de tests unitaires et fonctionnels et tous ces tests passent => TDD oblige
2. Lisibilité : Clair, expressif et cohérent : Le code fait apparaître séparément chaque responsabilité distincte (règle énoncé par K.Beck) => pour maitriser le code
3. Duplication : Le code ne fait apparaître aucune duplication => grace au refactoring : il garantit que le code n’est pas dupliqué ….
4. Complexité : Le code contient le nombre minimum d'élément (classes, méthodes, lignes) compatible avec les trois premiers critères => forcément le cas, on écrit le code minimal…
On écrit le code minimal pour couvrir le fonctionnel
D’abord qui marche ! …. Ensuite propre d’où le Mantra : Red Green Refactor…
Et en pratique qu’est-ce qu’on fait dans ces étapes ? Ectitr un trdt, code le mimimum pour que le test passe ..
Itération => possibilité d’apprendre de ces erreurs !!
Le développement dirigé par les tests (Test Driven Development ou TDD) est une approche itérative et incrémentale de codage piloté par des tests unitaires. C’est un
changement de paradigme en rupture avec les méthodes de programmation traditionnelles: les tests sont écrits avant le code et la conception devient émergente.
Plus qu’un cycle de développement, c’est une discipline exigente de programmation représentée par le mantra (Red-Green-Refactor). Ce cycle est très court, il ne doit pas dépasser quelques minutes : Être agile, c’est raccourcir la boucle de feedback pour pouvoir réagir au plus vite et s’améliorer.
« A l’image du potier qui travaille son argile en continu, le développeur travaille son code en permanence »
Benoit Gantaume (Junit)
Qui est développeur ?
Introduction au refactoring (s’il n’y a pas de développeurs)
Refactoring : Improving the Design
Design : Conception !
TDD : Clean Code that works
On vient de faire marcher le code, il faut maintenant le rendre Clean
Le code de la deuxième étape étant écrit au plus vite, un remaniement peut s’avérer nécessaire. Un remaniement consiste à changer la structure interne d’un logiciel sans en changer son comportement observable (Fowler, 1999).
La troisième étape commence alors à examiner la lisibité du code, sa complexité et son éventuelle duplication qui sont explicités par les acronymes KISS (Keep It Simple, Stupid) et DRY (Don’t Repeat Yourself). S’il y a remaniement, des techniques de refactoring sont mises en place en suivant une ligne directrice de conception guidée par des principes
Conception simple et évolution vs conception planifié…
D'où les techniques de "clean-code" et autres refactorings afin d'améliorer cette qualité au sens de maintenabilité et évolutivité.
Cette non qualité là se traduit par la métaphore de la dette technique. Duplication de code, complexité, manque de tests... Non pas que la dette technique soit en elle-même un problème. Cela le devient lorsqu'elle pose problème dans la relation entre le produit et le Développeur.
L'adhésion à cette pratique implique trois règles de conduite, sur lesquelles l'équipe appuie sa stratégie de conception logicielle:
- la conception est évaluée selon les 4 critères de simplicité énoncés par Kent Beck, ce qui suppose notamment la pratique du refactoring mais également l'adoption de l'heuristique YAGNI (voir définition ci-dessous), fort controversée;
- les éléments de conception tels que patrons de conception ou "design patterns", architecture à base de "plugins", etc. sont conçus comme ayant un coût et pas uniquement une valeur;
l'équipe cherche à différer aussi longtemps qu'il est possible de le faire de façon responsable les décisions importantes de conception, afin d'obtenir le plus d'information possible sur la pertinence de ces décisions avant d'en payer le coût
YAGNI, un acronyme qui signifie "You Aren't Gonna Need It", c'est-à-dire "Tu n'en auras pas besoin"; allusion à l'argumentation utilisée par certains programmeurs pour justifier une décision de conception
On commence par un test => Petit et en échec
Avec le minimum d’effort pour que le test passe au VERT => faire passer le test le plus rapidement possible et utiliser les ressources dont on dispose !
Ne pas oublier de relancer le test après l’implémentation ! => il doit être au vert !
Pas de duplication, pas de refactoring nécessaire ici, le code est clean (bon, propre)
A faire de manière individuelle !
Exigence: La maison doit être plus haute que la personne …
Si des petits malins ont levé la brique, rappeler que le programme doit être robuste et taper sur la table => le test doit être au rouge : aucune indication à present sur la taille !
Test pour répondre à l’exigence : (Est-il vrai que) la maison est plus haute que la personne ?
Un test vérifie une exigence.
Pour automatiser un test, on l’illustre alors par un exemple (il faut des valeurs ..) !
Pour moi, une exigence définit comportement et un test garantit un comportement ….
D’où dans ces transparents : exigences => doit & Test => ?
On commence par un test !!!!
A faire de manière individuelle !
Bien veillez à éviter l’over-enginneering (juste haute et large, pas plus !!! )…pas besoin d’aller plus loin et de fermer la maison (du moins jusqu’à cette iteration)
Itération n°4 : La maison doit être plus large que la personne … : laisser faire les participants !
RED : OK - A chaque nouveau test, nous apprenons de plus en plus sur les besoins de l’utilisateurs
GREEN : Implémentation Minimale pour faire passer le test : au choix de chacun !
REFACTOR : A voir =>
Bien veillez à éviter l’over-enginneering (juste haute et large)…pas besoin d’aller plus loin et de fermer la maison (du moins jusqu’à cette iteration)
… Parce que justement …
Satisfait toutes les exigences => Tout à fait : il n’y a aucune exigence à ce moment là ;-)
http://www.gargoylesoftware.com/ex/lego_simplicity
Nettoyer votre espace de travail en regroupant tous les LEGO® sur le côté.
Demander de séparer en deux tas de légo pour éviter d’avoir des problèmes de ressources !
Deux briques assemblées ne pourront en aucun cas être séparées c-à-d cune des briques utilisées ne pourra être enlevées
Le facilitera énoncera les exigences (les tests) une à une que les participants devront ensuite construire.
Les participants devront connaître l’objectif, à savoir que l' objectif est de construire une maison, mais ils ne connaîtrons pas les exigences spécifiques à l'avance et ne les découvrions qu’au fur et à mesure.
Une nouvelle exigence sera donné toutes les 30 secondes .
Au début , 30 secondes peut sembler trop long, mais ils vont se précipiter pour suivre une fois l'exercice se passe ..
→ Contrainte : Une fois que deux briques ont été assemblées, elles ne peuvent pas être en aucun cas séparées de nouveau .
Cela simule pas refactoring .…
On commence par un test => Petit et en échec
Avec le minimum d’effort pour que le test passe au VERT => faire passer le test le plus rapidement possible et utiliser les ressources dont on dispose !
Ne pas oublier de relancer le test après l’implémentation ! => il doit être au vert !
Pas de duplication, pas de refactoring nécessaire ici, le code est clean (bon, propre)
A faire de manière individuelle !
La maison doit avoir maintenant un toit plat…
Le commercial nous dit que « les toits en pente ne se vendent plus. "Marketing nous dit que les toits en pente ne se vendent plus . Si les acheteurs voient une pente, ils n’achèteront pas tant qu’il ne sera pas couvert..
60 secondes, au lieu de 30 , car étape plus difficile que les autres.
Mettre de côté les legos – ne pas les détruire
Satisfait toutes les exigences => Tout à fait : il n’y a aucune exigence à ce moment là ;-)
http://www.gargoylesoftware.com/ex/lego_simplicity
Nettoyer votre espace de travail en regroupant tous les LEGO® sur le côté.
Si assez de légo, on peut garder la première construction !
On mélange les tests !
Répéter à chaque itération :
Essayez de la faire le plus simplement possible : en un nombre minimum d’éléments, pas de complexité, pas de duplication et que tous les tests passent !
L’objectif de l’atelier était de montrer le genre de dette que nous accumulons si nous ne refactorisons.
Cet exercice permettra aux participants de faire l'expérience de la douleur face à la dette technique, plutôt que de simplement la comprendre …
Qu’avez-vous observé ? Qu’avez-vous ressenti lors de la 1ère itération ?
L'attente est que chaque étape va rendre l’étape suivante plus difficile.
Il faudra donc plus de temps pour la mettre en œuvre que ce qu'elle devrait .
Je donne habituellement 60 secondes pour le dernier , au lieu de 30 , car il est plus difficile que les autres.
Laquelle était la plus facile à construire ?
Nous entendons souvent " nous n'avons pas le temps de refactoriser " alors demandez si " l'acte de refactoring vous a ralenti ? "
Développement Classique : du Refactoring sur de la dette technique
Le développement dirigé par les tests (Test Driven Development ou TDD) est une approche itérative et incrémentale de codage piloté par des tests unitaires. C’est un
changement de paradigme en rupture avec les méthodes de programmation traditionnelles: les tests sont écrits avant le code et la conception devient émergente.
Plus qu’un cycle de développement, c’est une discipline exigente de programmation représentée par le mantra (Red-Green-Refactor). Ce cycle est très court, il ne doit pas dépasser quelques minutes : Être agile, c’est raccourcir la boucle de feedback pour pouvoir réagir au plus vite et s’améliorer.
« A l’image du potier qui travaille son argile en continu, le développeur travaille son code en permanence »
Benoit Gantaume (Junit)
La première étape consiste à écrire un nouveau test unitaire et vérifier qu’il échoue en obtenant une barre rouge dans un framework xUnit. Cela signifie que le test apporte un nouveau comportement à implémenter au code de production.
La deuxième étape consiste à écrire au plus vite un code de production pour faire passer le test précédent ainsi que les tests antérieurs. Tous les moyens sont bons pour obtenir une barre verte dans le framework xUnit, quitte à s’autoriser des solutions
incongrues (duplication, copier-coller,...).
Le code de la deuxième étape étant écrit au plus vite, un remaniement peut s’avérer nécessaire. Un remaniement consiste à changer la structure interne d’un logiciel sans en changer son comportement observable (Fowler, 1999).
TDD => un clean code that works => d’abord qui marche, après clean …
Pour obtenir des boucles de feedback fréquentes, ces trois étapes doivent être rapides, de quelques secondes à quelques minutes, et répétées aussi souvent que nécessaire. Ces itérations par petits pas (baby steps) permettent d’accroître la confiance des développeurs en leur code et un développement incrémental et continu du système. L’objectif du TDD est de produire rapidement un code opérationnel, puis propre.
Qui est développeur ?
Introduction au refactoring (s’il n’y a pas de développeurs)
Refactoring : Improving the Design
Design : Conception !
TDD : Clean Code that works
On vient de faire marcher le code, il faut maintenant le rendre Clean
Le code de la deuxième étape étant écrit au plus vite, un remaniement peut s’avérer nécessaire. Un remaniement consiste à changer la structure interne d’un logiciel sans en changer son comportement observable (Fowler, 1999).
La troisième étape commence alors à examiner la lisibité du code, sa complexité et son éventuelle duplication qui sont explicités par les acronymes KISS (Keep It Simple, Stupid) et DRY (Don’t Repeat Yourself). S’il y a remaniement, des techniques de refactoring sont mises en place en suivant une ligne directrice de conception guidée par des principes
Conception simple et évolution vs conception planifié…
D'où les techniques de "clean-code" et autres refactorings afin d'améliorer cette qualité au sens de maintenabilité et évolutivité.
Cette non qualité là se traduit par la métaphore de la dette technique. Duplication de code, complexité, manque de tests... Non pas que la dette technique soit en elle-même un problème. Cela le devient lorsqu'elle pose problème dans la relation entre le produit et le Développeur.
L'adhésion à cette pratique implique trois règles de conduite, sur lesquelles l'équipe appuie sa stratégie de conception logicielle:
- la conception est évaluée selon les 4 critères de simplicité énoncés par Kent Beck, ce qui suppose notamment la pratique du refactoring mais également l'adoption de l'heuristique YAGNI (voir définition ci-dessous), fort controversée;
- les éléments de conception tels que patrons de conception ou "design patterns", architecture à base de "plugins", etc. sont conçus comme ayant un coût et pas uniquement une valeur;
l'équipe cherche à différer aussi longtemps qu'il est possible de le faire de façon responsable les décisions importantes de conception, afin d'obtenir le plus d'information possible sur la pertinence de ces décisions avant d'en payer le coût
YAGNI, un acronyme qui signifie "You Aren't Gonna Need It", c'est-à-dire "Tu n'en auras pas besoin"; allusion à l'argumentation utilisée par certains programmeurs pour justifier une décision de conception
Demander de séparer en deux tas de légo pour éviter d’avoir des problèmes de ressources !
Deux briques assemblées ne pourront en aucun cas être séparées c-à-d cune des briques utilisées ne pourra être enlevées
Le facilitera énoncera les exigences (les tests) une à une que les participants devront ensuite construire.
Les participants devront connaître l’objectif, à savoir que l' objectif est de construire une maison, mais ils ne connaîtrons pas les exigences spécifiques à l'avance et ne les découvrions qu’au fur et à mesure.
Une nouvelle exigence sera donné toutes les 30 secondes .
Au début , 30 secondes peut sembler trop long, mais ils vont se précipiter pour suivre une fois l'exercice se passe ..
→ Contrainte : Une fois que deux briques ont été assemblées, elles ne peuvent pas être en aucun cas séparées de nouveau .
Cela simule pas refactoring .…
Qu’avez-vous observé ? Qu’avez-vous ressenti ?
Souvent, les gens observent que le test a forcé à construire dans un certain sens.
On dit que le test a guidé (conduit) la conception
Qui a rempli les cinq exigences de base ? (1 personne, 1 animal, 1 plante, 1 véhicule, 1 bâtiment)
En général, tout le monde ne l’a pas fait. Ils sont tellement occupés à créer des exigences intéressantes qu'ils ne disposent pas assez de temps pour construire les cinq choses que le client a effectivement demandé . En discuter … => rappel valeur métier de l’exercice 1 …
Est-ce qu’actuellement tous vos tests passent ?
Tous les tests au vert comportement garanti !
Parfois, les gens vont construire quelque chose de nouveau qui va cassé un test existant et soit ils ne l’auront pas remarqué, soit ils n’en tiennent pas compte. Si tel est le cas, discuter les tests doivent toujours être au vert (garantir le comportement)
Un petit coup d’œil sur les autres œuvres …
Revue : Demander aux participants de se lever et d’aller voir les œuvres des autres…
Suivie d’un Break Time (suivant temps) : Insister sur l’importance d’un break !!! Se lever et se détendre régulièrement !!!
OU
Démo par paire : 2 ou 3 fonctionnalités (faire sur un binôme par exemple)
Lire le test en premier et montrer ensuite comment cela a été implémenté dans le modèle
Rappel : s’il n’y a pas de test pour une fonctionnalité donnée, nous ne devrions pas la voir ;-)
Souvent, les gens auront construit des choses cool mais ils n’auront pas les tests associés ;-)
Soulignons encore qu’en TDD , nous ne devons pas si le test nous a pas forcé à le faire.
http://www.zazzle.fr/smiley+heureux+lapel+pins
Laquelle était la plus facile à construire ?
Nous entendons souvent " nous n'avons pas le temps de refactoriser " alors demandez si " l'acte de refactoring vous a ralenti ? "
« Grande construction » : Travail en paire où les paires sont obligés d’intégrer leur travail avec le reste de l’équipe !
Pair-programming & Intégration au sein de l’équipe
La "grande construction " dans laquelle chaque paire va devoir intégrer son travail avec le travail des autres paires .
Une équipe de 6 personnes en pair-building sur une même table.
Une équipe =une entreprise avec une super idée nécessitant une « grosse construction » (robot de cow-boy)
Chaque table devra procéder à une grande construction un peu complexe composée de petites constructions indépendantes et différentes
pouvant se connecter entre elles (à l’image d’un zoo, un aéroport, un parc d’attraction, un vaisseau spatial … mais pas d’un immeuble !)
+ : Un zoo : différents types d'expositions, des compteurs de billets et parkings : beaucoup de constructions différentes, qui pourtant se connectent …
- : Un immeuble traditionnel serait un mauvais projet, car il est le même à chaque étage , encore et encore
Extraits de : https://twitter.com/LEGOIdeas/status/767662715162730496
Construction + test
Magnifiques créations ! On fait le tour de quelques tables (suivant le temps…)
On fait le tour de quelques tables (suivant le temps…)
Lors de la démonstration : bien faire remarquer que tout ce qui est posé est couvert par les tests !
Pas de pièces de légo sans test !!
Pair-Demonstrating : 2 personnes de l’équipe pour présenter :
Une personne qui lit le test en premier
Une autre montre la construction qui fait passer ce test (comment cela a été implémenté dans le modèle)
Debriefer en même temps que la démo :
Qu’avez-vous observé ? Qu’avez-vous ressenti ? Question largement ouverte …
Observez les autres constructions. Est-ce que tous les tests passent ? En discuter . Souvent, les gens vont maintenant se rendre compte que quelque chose est cassé et qu’ils ne l’avaient pas remarqué . Cela peut conduire à une discussion sur les serveurs d'intégration continue .
Y aurait-il des tests qui devraient être réalisé et qui sont manquants ? Une fois qu'une équipe a construit un zoo et n'a pas terminé la clôture autour de l'enceinte de lion. Peut-être qu'ils avaient besoin d'un test pour vérifier que les lions ne pouvait pas sortir de manger tous les autres animaux .
Avez-vous eu un conflit où une nouvelle fonctionnalité d'une paire casse un test d'une autre ? Comment avez-vous traité ce problème ?
Est-ce que votre design final est différent de celui que vous attendiez ? En discuter
Bien vérifier que tout ce qui est implémenté est testé !
Sinon rappeler : s’il n’y a pas de test pour une fonctionnalité donnée, nous ne devrions pas la voir ;-)
Car souvent, les gens auront construit des choses cool mais ils n’auront pas les tests associés ;-)
Soulignons encore qu’en TDD , nous ne devons pas si le test nous a pas forcé à le faire.
C’est amusant car dans la présentation, on entend : « On souhaitait ci, ça … »
Pour décrire les tests, ce qui veut dire que les tests servent bien de documentation après coup et ont été considérés comme des spécifications !!!!
Développement Agile : Refactoring étape indispensable du TDD pour avoir du « Clean Code qui marche » (rappelez vous la définition du début …)
bien concevoir un logiciel est une valeur du manifeste du Software Crafsmanship !!!
DD est bien une méthode de Conception et non une méthode de test…
Une méthode de conception basé sur les tests et le refactoring…
Qui est développeur ?
Introduction au refactoring (s’il n’y a pas de développeurs)
Refactoring : Improving the Design
Design : Conception !
TDD : Clean Code that works
On vient de faire marcher le code, il faut maintenant le rendre Clean
Le code de la deuxième étape étant écrit au plus vite, un remaniement peut s’avérer nécessaire. Un remaniement consiste à changer la structure interne d’un logiciel sans en changer son comportement observable (Fowler, 1999).
La troisième étape commence alors à examiner la lisibité du code, sa complexité et son éventuelle duplication qui sont explicités par les acronymes KISS (Keep It Simple, Stupid) et DRY (Don’t Repeat Yourself). S’il y a remaniement, des techniques de refactoring sont mises en place en suivant une ligne directrice de conception guidée par des principes
Conception simple et évolution vs conception planifié…
D'où les techniques de "clean-code" et autres refactorings afin d'améliorer cette qualité au sens de maintenabilité et évolutivité.
Cette non qualité là se traduit par la métaphore de la dette technique. Duplication de code, complexité, manque de tests... Non pas que la dette technique soit en elle-même un problème. Cela le devient lorsqu'elle pose problème dans la relation entre le produit et le Développeur.
L'adhésion à cette pratique implique trois règles de conduite, sur lesquelles l'équipe appuie sa stratégie de conception logicielle:
- la conception est évaluée selon les 4 critères de simplicité énoncés par Kent Beck, ce qui suppose notamment la pratique du refactoring mais également l'adoption de l'heuristique YAGNI (voir définition ci-dessous), fort controversée;
- les éléments de conception tels que patrons de conception ou "design patterns", architecture à base de "plugins", etc. sont conçus comme ayant un coût et pas uniquement une valeur;
l'équipe cherche à différer aussi longtemps qu'il est possible de le faire de façon responsable les décisions importantes de conception, afin d'obtenir le plus d'information possible sur la pertinence de ces décisions avant d'en payer le coût
YAGNI, un acronyme qui signifie "You Aren't Gonna Need It", c'est-à-dire "Tu n'en auras pas besoin"; allusion à l'argumentation utilisée par certains programmeurs pour justifier une décision de conception
C’est une discipline, ce n’est pas simple…
Beaucoup de concept
Au même titre que les arts martiaux, TDD est une discplinen un art qui nécessaite un apprentissage…
On reparlera tout à l’heure des artisants logiciels au travers du software Crafstmanship
A la fois un apprentissage de concept technique au travers de livre …
« Grande construction » : Travail en paire où les paires sont obligés d’intégrer leur travail avec le reste de l’équipe !
Pair-programming & Intégration au sein de l’équipe
La "grande construction " dans laquelle chaque paire va devoir intégrer son travail avec le travail des autres paires .
→ Faire en sorte que les équipes ne puissent pas voir le travail des unes et des autres
S'il est impossible de séparer physiquement les groupes, essayez de les regrouper afin que les équipes soient en quinconce.
Par exemple , les équipes 1 et 3 à une table plutôt que 1 et 2 .
Préparer des post-it !
Chaque équipe va contruire quelque chose qui accueille le travail de l’équipe précédente… (mais ne pas le dire)
Péparer des post-it et les distribuer à chaque équipe pour qu’elle se rappelle ce qu’elle doit construire…
Evitez que les équipes voient ce que les unes et les autres construisent.
Qu’avez-vous observé ? Qu’avez-vous ressenti ?
Souvent, les gens observent que le test a forcé à construire dans un certain sens.
On dit que le test a guidé (conduit) la conception
Qui a rempli les cinq exigences de base ? (1 personne, 1 animal, 1 plante, 1 véhicule, 1 bâtiment)
En général, tout le monde ne l’a pas fait. Ils sont tellement occupés à créer des exigences intéressantes qu'ils ne disposent pas assez de temps pour construire les cinq choses que le client a effectivement demandé . En discuter … => rappel valeur métier de l’exercice 1 …
Est-ce qu’actuellement tous vos tests passent ?
Tous les tests au vert comportement garanti !
Parfois, les gens vont construire quelque chose de nouveau qui va cassé un test existant et soit ils ne l’auront pas remarqué, soit ils n’en tiennent pas compte. Si tel est le cas, discuter les tests doivent toujours être au vert (garantir le comportement)
Un petit coup d’œil sur les autres œuvres …
Revue : Demander aux participants de se lever et d’aller voir les œuvres des autres…
Suivie d’un Break Time (suivant temps) : Insister sur l’importance d’un break !!! Se lever et se détendre régulièrement !!!
OU
Démo par paire : 2 ou 3 fonctionnalités (faire sur un binôme par exemple)
Lire le test en premier et montrer ensuite comment cela a été implémenté dans le modèle
Rappel : s’il n’y a pas de test pour une fonctionnalité donnée, nous ne devrions pas la voir ;-)
Souvent, les gens auront construit des choses cool mais ils n’auront pas les tests associés ;-)
Soulignons encore qu’en TDD , nous ne devons pas si le test nous a pas forcé à le faire.
http://www.zazzle.fr/smiley+heureux+lapel+pins
Laquelle était la plus facile à construire ?
Nous entendons souvent " nous n'avons pas le temps de refactoriser " alors demandez si " l'acte de refactoring vous a ralenti ? "
Si ils ont livrés quelque chose et ne se remettent pas en question, les aider à pointer ce qui n’allait pas.
La plupart des groupes ne livrera pas à la première itération, certains ne livreront même pas au bout de trois itérations.
Cette fois-ci si les équipes souhaitent se parler les unes aux autres, il ne faut pas les décourager…
Mais nous n’allons pas non plus le leur suggérer.
Lorsque le temps est écoulé , intégrer toutes les pièces. Chaque équipe apporte sa(ses) pièces et on intègre sur une table vide commune.
Y avait-il des personnes debout pour passer d’une table à l’autre pendant l’intégration ?
Lors de l’intégration, les personnes devraient sourire car elles prennent conscience de leurs erreurs.
Qu’avez-vous observé ? Qu’avez-vous ressenti ?
Souvent, les gens observent que le test a forcé à construire dans un certain sens.
On dit que le test a guidé (conduit) la conception
Qui a rempli les cinq exigences de base ? (1 personne, 1 animal, 1 plante, 1 véhicule, 1 bâtiment)
En général, tout le monde ne l’a pas fait. Ils sont tellement occupés à créer des exigences intéressantes qu'ils ne disposent pas assez de temps pour construire les cinq choses que le client a effectivement demandé . En discuter … => rappel valeur métier de l’exercice 1 …
Est-ce qu’actuellement tous vos tests passent ?
Tous les tests au vert comportement garanti !
Parfois, les gens vont construire quelque chose de nouveau qui va cassé un test existant et soit ils ne l’auront pas remarqué, soit ils n’en tiennent pas compte. Si tel est le cas, discuter les tests doivent toujours être au vert (garantir le comportement)
Un petit coup d’œil sur les autres œuvres …
Revue : Demander aux participants de se lever et d’aller voir les œuvres des autres…
Suivie d’un Break Time (suivant temps) : Insister sur l’importance d’un break !!! Se lever et se détendre régulièrement !!!
OU
Démo par paire : 2 ou 3 fonctionnalités (faire sur un binôme par exemple)
Lire le test en premier et montrer ensuite comment cela a été implémenté dans le modèle
Rappel : s’il n’y a pas de test pour une fonctionnalité donnée, nous ne devrions pas la voir ;-)
Souvent, les gens auront construit des choses cool mais ils n’auront pas les tests associés ;-)
Soulignons encore qu’en TDD , nous ne devons pas si le test nous a pas forcé à le faire.
http://www.zazzle.fr/smiley+heureux+lapel+pins
Laquelle était la plus facile à construire ?
Nous entendons souvent " nous n'avons pas le temps de refactoriser " alors demandez si " l'acte de refactoring vous a ralenti ? "
Artiste ou artisant, on peut se poser la question …
On connaît bien des virtuoses de code, et même des développeurs qui sont de drôles d’artistes ;-)
Pour moi un artiste est quelqu’un qui est au sommet de son art … qui générère des ouahhh et montre les chemin…
Par exemple, D. Gageot et le kata Gilded Rose est une rock star du code,
Ou Sandro Mancuso…mais qui dit Live Coding, dit aussi beaucoup de travail derrière !!!!