Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Agile France - Software Craftsmanship - Juin 2019
Ähnlich wie Agile France - Software Craftsmanship - Juin 2019 (20)
Agile France - Software Craftsmanship - Juin 2019
- 1. SOFTWARE CRAFTSMANSHIP BACK TO BASICS Frédéric Faure #AgileFrance 2019 http://agile-paysbasque.fr
- 2. Prolégomènes • Je n’ai pas de certitudes • Je ne suis pas à une contradiction près • Je n’ai pas d’avis sur git rebase vs git merge
- 3. Qui suis-je ? • Un informaticien agiliste • Un zenikaien okiwiste https://twitter.com/ffaure32
- 6. Les principes du manifeste agile
- 7. Soudain, c’est le drame
- 8. The new new manifesto
- 9. Le Software Craftsmanship : qu’est-ce à dire?
- 15. Propriété collective du code
- 16. Code Review
- 17. Tu ne tueras point, même s’il a mis des tabulations à la place d’espaces
- 18. Pair Programming
- 20. Standards de développement • Validés par toute l’équipe • Explicites pour toute l’équipe • Automatisés pour toute l’équipe
- 21. Test Driven Design/Development « Le doute n’est pas une condition agréable, mais la certitude est absurde » Voltaire
- 24. Dette technique
- 25. No comment…
- 26. No doc no cry ?
- 29. YAAL (Yet Another Acronym List) • KISS • YAGNI • SOLID • DDD
- 30. La simplicité est essentielle « L'homme devrait mettre autant d'ardeur à simplifier sa vie qu'il en met à la compliquer. » Henri Bergson
- 31. Four Rules of Simple Design – Kent Beck • Passer les tests • Minimiser la duplication • Maximiser la clarté • Favoriser la réduction du code
- 32. SOLID « Pour les questions de style, nage avec le courant; sur les questions de principe, sois solide comme un roc. » Thomas Jefferson https://vimeo.com/157708450
- 33. DDD « Mal nommer un objet, c'est ajouter au malheur de ce monde » Albert Camus
- 34. Attitude • Boyscout Rule • Egoless programming • Fenêtre cassée • Soupe au cailloux
- 35. Comment donner l’exemple • Coding dojo • Club de lecture • BBL • Meetup et Confs (Ncrafts, Socrates) • Code Retreat • Geek Camp • Crafts Swap
- 36. Conclusion « Essayons de coder proprement, ne serait-ce que pour donner l’exemple » Bob Prévert
Hinweis der Redaktion
- Ma phrase fétiche : tout ce que je sais c’est que je ne sais rien (Socrates) On va donc parler craftsmanship. avertissement, ca ne va pas forcément être une présentation avancée du sujet. Je n’ai pas d’idée révolutionnaire et je vais pas montrer de code ni faire de live coding… Je m’appuie sur les écrits des autres, je risque de lâcher un certain nombre de noms. Attention à la violence symbolique et le name dropping. Ne pas hésiter à me demander de clarifier (genre si quelques gens rient à une blague et pas les autres,si c'est parce qu'ils n'ont pas la référence, demander des précisions. Bon, si c'est juste pas drôle...)
- Frédéric Faure, 20 ans que je fais du java (et d’autres choses), plus de 12 ans d’agilité. Et pour moi, les 2 vont très bien ensemble et se marient dans le craftsmanship Zenika depuis bientôt 3 ans, boite sympa, une 20taine sur bordeaux, des devs et des agilistes Okiwi, asso depuis plus de 10 ans, commencé en 2008, on a organisé l’AT en 2009 au Labri. Depuis, plein de trucs sympas, ils soutiennent tjs l’AT, organisent le GeekCamp, le GDCR, les coding dojo du lundi, et cette série sur le crafts. C’est bientôt l’AG, n’hésitez pas à cotiser 20 ans avec cette photo d’il y a 20 ans La même avec 15 kg de plus et un costard en moins Comme je continue à faire du code je me sens un peu comme ca parfois
- Faut bien comprendre d’où l’on vient pour savoir ou on va Et donc à ma connaissance, les premières références à l’artisanat apparaissent dans un livre référence dont on reparlera « The pragmatic programmer » dont le sous-titre est « from journeyman to master » qu’on peut traduire par « de compagnon à maitre ». Il date de 1999 (édition anniversaire cette année) Il y a ensuite un livre plus explicite « Software Craftsmanship » en 2001 mais j’avoue ne l’avoir pas lu
- J’ai fait une petite dizaine de présentations et je ne me souviens pas en avoir fait sans cette bonne vieille image dégueulasse du manifeste agile On est sur le dev logiciel (cf. la phrase si souvent oubliée en haut du manifeste), parmi les signataires, beaucoup de développeurs
- Le développement et la qualité logicielle font partie intégrante du manifeste agile.
- Fin des années 2000 ont vu poindre un certain nombre d’articles se plaignant de ce que scrum avait fait de l’agilité (techniquement, certains sont arrivés après mais c’est pour appuyer mon propos). Je me souviens d'avoir proposé à l'ATBDX 2010 de poser comme thème "la crise d'adolescence de l'agilité". Ca s'est pas amélioré De + en + de gens ont commencé à reprocher ce qui avait été fait de l’élan initial : Certifications, monétisation, consulting, serious games, etc
- À la keynote d’Agile 2008 Oncle Bob propose d’ajouter une 5ème valeur au manifeste Agile : “Craftsmanship over Crap”, il proposera plus tard de la renommer en “Craftsmanship over Execution”. Décembre 2008 : Software Craftsmanship Summit où le manifeste est rédigé 2009 : Manifeste du Software Craftsmanship Honnêtement, quand on lit ce nouveau manifeste, rien de révolutionnaire. Et design toujours aussi moche.
- Utilisé cette image par flemme vu que j’avais fait une conf d’expert beginner sur la philo, que j’avais pompeusement appelé « le workhackisme… » J’avais d’ailleurs pensé appelr ce talk le Softwarisme est un Craftsmanisme… Le Craftsmanship est avant tout un état d’esprit, une philosophie, c’est avant tout des rencontres #EdouardBaer. C’est pas ces mecs avec leurs macs pleins d’autocollants qui viennent parler à des confs
- Métaphore de l'artisanat et du compagnonage : - transmission de la connaissance - communauté de compagnons - aspirant compagnon formé via des pratiques éducatives encadrées. - L'aspirant devient ensuite compagnon lui même attention danger sectaire (rites de passage) Perso, internationaliste, prosélyte, je vois un intérêt à ce que cela se déploie au plus grand nombre - l'importance du bon outil (il achète pas dans les prix jaunes des étagères du bas Leroy Merlin) -> bon ide et bien connaitre le langage (débat?) Et c’est pas pour ca qu’on va pas sur stackoverflow 4*/heure
- dès qu'on bosse avec des artisans (électriciens, couvreurs) leur premier réflexe c'est de dire "mais c'est qui le sagouin qui a bossé sur votre installation, faut tout refaire, c'est n'importe quoi". Ca vous rappelle rien ? prime directive « Indépendamment de ce que nous découvrons, nous comprenons et nous croyons sincèrement que chacun a fait du mieux qu’il pouvait, compte tenu de ce qu’il savait à l’époque, de ses compétences et de ses prérogatives, des ressources disponibles et de la situation du moment. » Par contre, effectivement, on va pas aller dire à son couvreur comment travailler.
- Il y a une quasi bijection entre adepte du craftsmanship et ceux d’eXtreme Programming Pour mémoire, agilité issue surtout de Scrum & XP. A la base, plutôt copains. Ont beaucoup échangé sur les pratiques et sont pas opposés. Par contre, ça s’est gâté par la suite. Scrum effectivement pas prescriptif sur la qualité. Mais pas beaucoup plus sur l’orga. XP l’est plus sur tout. Alors oui, faut dire les choses comme elles sont, Scrum a gagné. Comme l’anglais vs l’esperanto. Je ne connais pas un xprogrammer qui ne dise du mal de Scrum. Et je ne connais pas de Scrummer qui dise du mal d'xp. Ceci étant dit, je suis personnellement agnostique et on va donc parler des pratiques d’XP On va donc étudier d’un peu plus près le contenu d’XP
- Projet de refonte du le système de paie, C3 chez Chrysler (Chrysler Comprehensive Compensation) avec Kent Beck en chef de projet (père du TDD, de XP, JUnit), Ward Cunningham (Wiki, XP) et Ron Jeffries (XP), tous trois signataires du manifeste agile. Le principe est de pousser toutes les bonnes pratiques à l’extrême : Intégration fréquente -> intégration continue Itérations courtes -> 1 semaine Tests unitaires -> TDD Etc.
- Les pratiques d’XP telles que présentées en 99. Ca n'est pas des pratiques d'ingénierie logicielle (et c’est moche, c’est peut être une des raisons pour lesquelles xp a perdu) Des pratiques sur la gestion du projet (petites releases, planning game, équipe complète, tests utilisateur) xprogramming.com -> ronjeffries.com
- Mis volontairement une image naïve mais c’est clairement un objectif, un idéal de fonctionnement. Le code n’appartient à personne, pas de chasse gardée Tout le monde doit pouvoir agir sur n’importe que partie de l’application On évite la spécialisation à outrance (T-Shaped) Certaines pratiques de code d’XP favorisent cet objectif
- OK, c’est pas une pratique d’XP Je sais que ce n'est qu'un mode dégradé du pair programming, que ça s'inscrit mal dans du Trunk Based Development et que c'est souvent pénible à faire. Mais ça contribue à la propriété collective du code et il peut toujours y avoir des biais sur un binôme qui seront corrigés par la revue
- On en a même fait des commandements dans une boîte dont je tairai ou pas le nom. Pas la peine de regarder le détail des items, certains vous feront peut être bondir mais ces commandements sont contextuels. Idée de bienveillance, de faire un minimum de chose avant de pousser du code (c’est déjà validé en interne, c’est fonctionnel, ca compile, c’est testé, ca respecte les conventions de codage, c’est petit). On rend explicite les choses.
- Sondage main levée (Qui est ici ? Qui fait des revues ? Du pair de tps en tps ? Du pair tout le temps ? Du mob tps en tps ? Mob tt le tps ?) Pair programming -> revue de code poussée à l’extreme Pair programming tout le temps -> pair programming poussé à l’extreme Mob programming -> pair programming tout le temps poussé à l’extreme Ca sert à quoi : efficacité immédiate (éviter les fautes de frappes, rubber ducking) à moyen/long terme (sur la propriété collective du code, apprentissage : technique de code, raccourcis clavier)
- C’est putain de pas facile. Beaucoup de gens, notamment chez les devs sont plutôt introvertis, aiment bien bosser dans leur coin et pousser leur propre idée jusqu’au bout (moi le premier) Mais il faut réussir à aller contre son penchant naturel. Débat sur les revues de code : faut-il en faire même si on est en pair proagramming ? Faut il faire des PR et des revues sur du Trunk Base Dev ? Faut-il faire du Trunk Based ? Guess what ? J’ai pas d’avis. Enfin si, j’en ai 1000. J’ai commencé sans gestionnaire de sources (un répertoire partagé sur un serveur). Découvert CVS. Quand SVN est arrivé… Quand Git est arrivé… etc.
- Format du code Convention de nommage Documentation du code Validation d’une pull request ? Definition of Done Definition of Ready ? Automatiser le plus de choses possibles (à la fois l’application et leur vérification) Standards de code sans CI, ça sert pas à grand-chose Super utile pour facilement entrer dans un code, contribue grandement à la propriété collective du code
- - Ca contribue à la propriété collective du code: beaucoup moins de mal à changer des choses si on est couvert par des tests - Red/green/refactor : le plus important est sans doute le refactor et c'est souvent la partie oubliée qui fait que TDD ne marche pas - rappeler les 3 règles du TDD d'Uncle Bob et dire qu'il faut s'en méfier (car la notion de refacto n'apparait pas vraiment) - - addiction à la barre verte - pas un ayattolah mais j'ai constaté que quand je faisais tu test after, mes tests étaient moches et étaient vraiment des reproductions de l'implémentation - penser aussi au refactoring des tests. Notre capacité à générer une base de tests inconstistante à base de copier/coller est énorme (souvenez vous votre dernier dojo ou le hashcode) - Règle des 3 A (avec template)
- Très difficile de faire du refactoring sans tests (définition de legacy : code non testé) En dev, refactor mercilessly. C’est le moment ou c’est simple, dans chaque boucle de TDD. Eliminer les duplication, extraire les constantes, extraire les méthodes, extraire les concepts. Je suis peut être un usurpateur. J’ai une carrière de 20 ans de développeurs basée sur le seul principe de l’extract method Le refacto se fait au fil de l'eau (TDD), on fait pas des stories de refacto (sauf legacy ou dette technique, on en reparle)
- Sauf qu’on est pas toujours dans ce monde idéal. Parfois, on arrive dans un océan de legacy. Pas testé. Du code dégueulasse. Hyper couplé. Confession : j’adore ça. Mais se lancer du refacto sur du legacy, c’est, pour citer Joey Star, toujours classe « traverser un océan de merde sans tuba » D’abord, on peut appliquer les quelques refactos de base pilotés par l’IDE (IntelliJ notamment est très fort pour ça). On extrait des bouts de code, on fait quelques concessions (on met du protected pour pouvoir tester de l’extérieur, etc) et on met des coutures (seams, principe fondamental du bouquin working effectively with legacy code) Solution plus avancée : golden master. "Working effectively with legacy code)
- Tout le monde a ce mot à la bouche. Incompréhension initiale : une dette technique ca se contracte sciemment et ca se rembourse (c’est pas de moi). Ca doit rester une décision consciente de la part du donneur d’ordre et pas de l’équipe technique. C’est pas en dev qu’on se dit « ouais, c’est pas très propre mais on le corrigera plus tard » J’ai qu’à mettre un commentaire, avec un TODO ou FIXME, etc. La seule raison qui pourrait justifier de la contracter serait une décision métier (liée potentiellement à du cost of delay). Mais alors, l’équipe technique doit se transformer en huissier, en agence de recouvrement. Elle doit rendre le plus explicite la dette et ses intérêts. accidental complication de Jeff Rainsberger Articles de Christophe Thibeault
- Dans la dette involontaire, y a les commentaires ce n'est pas le mal absolu mais c'est un indice, une invitation au refacto
- Les commentaires, ça pourrait être de la doc Souvenons nous le 2ème pilier du manifeste agile « logiciel opérationnel plus que documentation exhaustive » mais attention à ne pas oublier la partie de droite De la doc utile : de la doc lue et facilement maintenable -> Livre de cyrille Martraire (Living Documentation) ou de Gojko Adzic (Specification By Example)
- Contribue également à la propriété collective du code en ayant de la propriété collective du build Facilite le chemin vers le Trunk Based Dev Exige : Une couverture de tests maximale Des solutions de rollback hyper rapides (redéploiement facilité par infrastructure as code et infrastructure immutables) Du feature flipping
- Tant qu’on en est à parler des TU, de la couverture, des pipelines de build, faut bien parler du débat sur le taux de couverture de code Déjà, de quoi parle-t-on ? Si on se limite au line coverage… Branch, conditions, etc. On est globalement tous d'accord, fixer un objectif de couverture de code, c'est mal : - loi de Goodhart (quand une mesure devient la cible elle cesse d’être une bonne mesure) mais surtout loi de Campbell (plus un indicateur quantitatif est utilisé pour la prise de décision, plus il a de chances de fausser et corrompre le processus qu’il a pour objet de surveiller) - > tests sans assertions (penser au mutation testing) - un tx élevé ne me garantit rien. En revanche, un taux bas m'inquiète directement. Donc c'est intéressant à mesurer mais pas à objectiver
- Je cite du Bergson juste pour imposer ma violence symbolique, je l’ai jamais lu, hein Keep It Simple Stupid -> Les conceptions simples sont les plus faciles à comprendre et à faire évoluer. On a une tendance naturelle à l’anticipation, à la complexité. Alors que YAGNI. Certains ont même le défaut de faire des choses volontairement compliquées, peut être pour imposer leur violence symbolique, montrer leur domination. on est pas des créateurs de fwks. Y en a même qui disent que les fwks, c’est le mal. On fait de la conception simple.
- S’il y a un slide à retenir, c’est celui là. Y a 50 versions exprimant ces règles. Ca apparait pour la 1ère fois dans le livre de Beck. On peut faire du refacto une fois que les tests passent. Pour faire passer les tests, on peut faire du copier/coller mais une fois fait, il faut refacto ! Jeff Rainsberger a écrit un article intéressant pour réduire le sujet
- SOLID : J’en fais pas une religion, je reste attaché à la logique de découplage (cf. Kevlin Henney) Ca sert à briller en société, surtout le principe de subsitution de liskov (composition > inheritance). Ca peut me service d’alerte, d’invitation au refacto Attention aux dérives : Interface Hell (des interfaces partout alors que vraiment, on est sûr d’avoir qu’une seule implem). Framework envahissant (Spring I’m watching you) qui ajoute tellement de magie qu’on peut plus faire d’injection manuelle de dépendance (par constructeur ou mutateur) Séparer les responsabilités, bien nommer les choses, éviter les effets de bords, penser immutabilité, lutter contre la primitive obsession (et créer de vrais value objects) Eviter d’hériter de classes du langage
- J’AI PAS LU LE BLUE BOOK mais je retiens un certain nombre de principes de DDD. Notamment l’ubiquitous language et les bounded contexts (bon, je prends aussi les Value Objects, les entités) le concept de langage commun entre métier et devs et fondamentale -> expérience dans le monde de l’hopital ou la complexité de nommer les différentes composantes d’un séjour à l’hopital était énorme (séjour, hospit, événèment, mouvement, etc) le tout dépendant du contexte (bounded context :pas le même métier du point de vue administratif et du point de vue purement médical ou soignant). Sauf que c’était mélangé dans le code avec des abstractions au mauvais endroit. Arrêter aussi avec les objets anémiques
- Boyscout rule : on ne peut pas tout refacto dans du legacy. On le fait quand on a besoin de toucher à un bout de code Egoless (Jerry Weinberg) : fier mais pas dupe Fenêtre cassée : cf. Rudolf Guiliani (maire de NY dans les années 90, pas forcément un exemple sur tout). Rejoint la boyscout rule Soupe au caillou : entraide, l’exemplarité DONNER l’EXEMPLE
- Quelle que soit la mission (j’ai fait du coaching technique, j’ai été Scrum Master, j’ai fait du « consulting agile », je suis actuellement PO)
- se hisser que les épaules des géants, écouter Kent Beck, henley, rainsberger, Arnaud Lemaire Rapprocher agilistes et craftsmen qui n'auraient pas dû se séparer (Alpes Crafts) notre vocation est de faire des logiciels qui simplifient la vie de l'utilisateur et non qui la complexifient (cf terminaux dans le commerce connectés à des gros systèmes qui marchaient super bien et qui ont été remplacés dans les années 2000 par des applications web buggées) Se recentrer sur le métier, au plus près des utilisateurs et experts métiers Métaphore de la brique/du mur/de la cathédrale. Perso, je construit des murs les plus utiles qui soient et j’aime pas trop les cathédrales (un peu trop d’over engeneering)