Lego bonnes pratiques_devoxx_2017
•
1 gefällt mir•507 views
Atelier TDD LEgo présenté à Devoxx
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Lego bonnes pratiques_devoxx_2017
Ähnlich wie Lego bonnes pratiques_devoxx_2017 (20)
Mehr von Alice Barralon
Mehr von Alice Barralon (9)
Lego bonnes pratiques_devoxx_2017
- 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
- 5. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON Matière première …
- 6. #DevoxxFR Simple pour commencer Construire une maison et une personne. 6
- 7. #DevoxxFR Admirez et partagez ! #TDDLego 7
- 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
- 11. #DevoxxFR Quid du programme informatique parfait ? Show.me.the.code> 11
- 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
- 15. #DevoxxFR Make them FIRST Fast Isolated Repeatable Self-verifying Timely 15 La bonne conception n’est jamais la première… … elle émerge.
- 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
- 22. #DevoxxFR Prêt pour une nouvelle mission ? 22
- 23. #DevoxxFR Refactoring: pour minimiser la dette technique ! 23 Descriptif original de l’atelier disponible sur : http://www.gargoylesoftware.com/ex/technical_debt
- 24. #DevoxxFR Refactoring interdit ! > 2 murs connectés 24
- 25. #DevoxxFR Refactoring interdit ! > 2 murs connectés > une fenêtre sur un mur 25
- 26. #DevoxxFR Refactoring interdit ! > 2 murs connectés > une fenêtre sur un mur > entièrement fermée 26
- 27. #DevoxxFR Refactoring interdit ! > 2 murs connectés > une fenêtre sur un mur > entièrement fermée > un toit en pente 27
- 28. #DevoxxFR Refactoring interdit ! > 2 murs connectés > une fenêtre sur un mur > entièrement fermée > un toit en pente > une cheminée 28
- 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
- 33. #DevoxxFR Refactoring autorisé ! > 2 murs connectés 33
- 34. #DevoxxFR Refactoring autorisé ! > 2 murs connectés > une fenêtre sur un mur 34
- 35. #DevoxxFR Refactoring autorisé ! > 2 murs connectés > une fenêtre sur un mur > entièrement fermée 35
- 36. #DevoxxFR Refactoring autorisé ! > 2 murs connectés > une fenêtre sur un mur > entièrement fermée > un toit en pente 36
- 37. #DevoxxFR Refactoring autorisé ! > 2 murs connectés > une fenêtre sur un mur > entièrement fermée > un toit en pente > une cheminée 37
- 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
- 41. #DevoxxFR La plus facile à construire? Refactoring ralentit-il? #TDDLego 41
- 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
- 47. #DevoxxFR Kata : TDD et pair-programming > 1 personne > 1 véhicule > 1 pont 47
- 48. #DevoxxFR Qu’avez-vous ressenti ? Quid des 3 exigences ? Tous les tests passent ? 48
- 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
- 53. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON TDD : Les références ET Confiance
- 54. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON
- 55. #DevoxxFR Intégration continue 55 e sur : http://www.gargoylesoftware.com/ex/lego_continuous_integration
- 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
- 63. #DevoxxFR 63
- 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 ?
- 66. #DevoxxFR Références 66 Descriptif original de l’atelier disponible sur : http://www.gargoylesoftware.com/ex/technical_debt
- 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
- 73. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON Merci à Denis Benoist pour ce Sketchnoting !
- 74. #DevoxxFR Isabelle BLASQUEZ – Alice BARRALON Crédits Photos https://www.flickr.com/photos/3n/452975317/ (postit) http://www.boost.co.nz/blog/2013/11/what-does-lego-and-building-high-quality-software-have-in-common/ http://blog.octo.com/coder-a-pas-de-chaton-a-lecole-du-tech-lead/ http://www.frenchweb.fr/craftsman-lartisan-du-code/221948 http://www.drims-academy.fr/author/athiefaine/ http://blogs.atlassian.com/2009/06/pair_programming_is_kryptonite/ http://www.passetoncode.fr/cours/feux-tricolore http://www.bbbpress.com/2015/06/drama-game-index-card/ http://prettypoun.centerblog.net/6587339-materiel-scolaire-rentree-des-classes-tableau-de-classe http://www.supportduweb.com/generateur-de-post-it-web-20-sites-note-bloc-image-post-it-texte.html http://www.icone-png.com/png/54/53878.png http://www.creavea.com/activite-manuelle-enfant_boule-a-neige-diy-personnalisable-lego_fiches-conseils_4443-0.html http://jaysbrickblog.com/2012/07/27/lego-olympics-team-gb-minifigures-review/ http://www.cloveretl.com/blog/new-features-cloveretl-4-0/ https://roadmender.net/2014/05/07/legos-on-my-mindcollaboration-and-the-integration-of-bits https://twitter.com/Factor41Play/status/653840058500403200 https://twitter.com/sahithyaW/status/428217265667198976 https://twitter.com/JeffHoover/status/515550469175799808 https://twitter.com/iGeaux/status/515550799045607424 https://twitter.com/iGeaux/status/515554621629415424 https://twitter.com/khellang/status/626716128379830273 https://twitter.com/LEGO_Group/status/710496008795336704 https://twitter.com/LEGO_Group/status/756126659057561600 https://twitter.com/LEGO_Group/status/767013378371952640 https://twitter.com/LEGOIdeas/status/760814604003999744 https://twitter.com/LEGOIdeas/status/767662715162730496 Briques disponibles sur : http://shop.lego.com/
- 75. #DevoxxFR Merci / Thank you / Gracias / Milesker 75
Hinweis der Redaktion
- 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 !!!!
- http://images.google.fr/imgres?imgurl=http%3A%2F%2Fwww.karatedo-fudoshin-plescop.fr%2Fpages%2Fimages%2Fardoise.png&imgrefurl=http%3A%2F%2Fwww.renders-graphiques.fr%2Fforum%2Fviewtopic.php%3Ft%3D39790&h=1024&w=1280&tbnid=cbwT4Jg6p-ZcgM%3A&docid=m6IK1S1EtvcLxM&ei=QhPDV66LKYHca-GpgegM&tbm=isch&iact=rc&uact=3&dur=2454&page=0&start=0&ndsp=42&ved=0ahUKEwiutJDlxeTOAhUB7hoKHeFUAM0QMwgsKAgwCA&bih=847&biw=1706
- http://www.gargoylesoftware.com/ex/lego_clean_code But : Montrer la valeur de garder du code propre
- Les exigences fournissent des contraintes à la fois qualitatives et quantitatives sur la conception ultérieure du système et sur sa mise en œuvre.
- Les exigences fournissent des contraintes à la fois qualitatives et quantitatives sur la conception ultérieure du système et sur sa mise en œuvre.
- Les exigences fournissent des contraintes à la fois qualitatives et quantitatives sur la conception ultérieure du système et sur sa mise en œuvre.