Ratez vos revue de code en 5 lecons devoxx fr 2016Michel Domenjoud
La revue de code, tout le monde connait, bien sûr. C'est d'ailleurs une des plus vieilles pratiques de développement, dont l'efficacité est prouvée depuis longtemps pour détecter des défauts au plus tôt. Alors pourquoi tant d'équipes n'utilisent elles pas la revue de code, ou n'en tirent pas les bénéfices qu'évoquent de nombreuses études ? Au cours de cette session, on explorera quelques uns des nombreux écueils à éviter, au travers de situations de revue de code qui se passent mal, et on proposera des pistes pour corriger le tir.
Presentation faite à Agile France en 2011
La revue de code : c’est facile !
Cette présentation est la suite de la session « La revue de code : c’est agile, c’est lean, c’est indispensable ! » présentée à Agile France et Agile Tour en 2010.
Après avoir répondu aux idées reçues sur la revue de code et avoir montré combien une revue de code systématique soutient une démarche agile et lean, cette présentation se focalise sur la mise en place de la revue de code comme étape incontournable du processus de développement.
Nous évoquerons les bonnes pratiques, les difficultés à la mise en place, les pièges à éviter et aussi les outils qui facilitent la revue de code. Une grande partie de la présentation sera dédiée à plusieurs démonstrations, exemples et retours d’expérience.
Votre projet marche, mais c'est le chaos. Comment arrêter de dépendre de ces "héros" sur qui tout repose ?
Présentation vidéo : https://youtu.be/aClcNdOqtsE
Suite à ma lecture de "The Software Craftsman" de Sandro Mancuso, je présente ce qu'est le Software Craftsmanship.
Présentation visible sur YouTube : https://youtu.be/RW0-QIJttBM
Introduction aux spécifications exécutables (dit aussi atdd, bdd)Jean-Pierre Lambert
Comment s'assurer que tout le monde parle la même langue dans l'équipe ? Et ainsi éviter les retours de recette ?
Utiliser des spécifications exécutables, ou ses cousins le ATDD (Acceptance Test Driven Development) et le BDD (Behavior Driven Development), est un élément de réponse particulièrement pertinent. Cette méthode est également un point d'entrée puissant vers une stratégie d'automatisation des tests.
Dans cette présentation vous découvrirez les tenants et les aboutissants de cette méthode, et repartirez les poches remplies de conseils de mise en place.
Deployer en continu, Benoît Lafontaine, USIEVENT 2013Benoît Lafontaine
Presentation played at USIEVENT 2013, see the presentation on youtube: http://www.youtube.com/watch?v=UcDtH5s406M&feature=share&list=PLyzb9DL11tdZBlz6nY8TZxMcqVf04K5wY
La revue de code : agile, lean, indispensable !Lucian Precup
Présentation faite à Agile France en 2010 :
La revue de code : agile, lean, indispensable !
Alors que l’intégration continue ou les tests unitaires commencent à rentrer dans les "standards", la revue de code est souvent considérée comme optionnelle. Pourtant, les avantages d’une revue de code systématique sont multiples : détection des anomalies très tôt dans le cycle de développement, formation des membres de l’équipe, partage de la connaissance, meilleures solutions techniques par la conjonction des perspectives développeur/examinateur.
Cette présentation mettra en évidence les avantages de la revue du code en répondant aux idées reçues comme "la revue du code augmente la durée des développements", ou "nos développeurs sont très bons, ils n’ont pas besoin de revue de code" ou encore "il n’y a personne dans l’équipe qui puisse examiner mon code car je suis le seul à connaître Bash et Ant". En évoquant la revue de code dans l’univers open source, les différents moyens de la mettre en œuvre, ses compléments, les différents outils ; et terminant par une démonstration concrète en utilisant Eclipse, Bugzilla et Mylyn, cette présentation vous convaincra de mettre en place la revue de code systématique dans votre équipe sans attendre.
Déroulement :
1/ Avantages
2/ Idées reçues
3/ La revue de code dans l’univers open-source : de la revue du patch par le committeur aux procédures très élaborées comme celles de Mozilla Developer Center.
4/ Moyens de mise en œuvre : à partir de quelle taille des projets, par qui, comment, avant l’intégration ou après, ...
5/ Les compléments de la revue du code : analyse de la qualité du code, scripts pour les normes internes, ...
6/ Comparaison avec d’autres techniques : pair programming, ...
7/ Outils et intégration avec les autres outils de développement ou de gestion du cycle de vie (intégration continue, gestion des anomalies, ...)
8/ Démonstration des avantages sur un exemple concret en utilisant Eclipse, Bugzilla et Mylyn comme outils.
9/ Conclusion : comment la revue de code supporte une démarche agile et lean
Ratez vos revue de code en 5 lecons devoxx fr 2016Michel Domenjoud
La revue de code, tout le monde connait, bien sûr. C'est d'ailleurs une des plus vieilles pratiques de développement, dont l'efficacité est prouvée depuis longtemps pour détecter des défauts au plus tôt. Alors pourquoi tant d'équipes n'utilisent elles pas la revue de code, ou n'en tirent pas les bénéfices qu'évoquent de nombreuses études ? Au cours de cette session, on explorera quelques uns des nombreux écueils à éviter, au travers de situations de revue de code qui se passent mal, et on proposera des pistes pour corriger le tir.
Presentation faite à Agile France en 2011
La revue de code : c’est facile !
Cette présentation est la suite de la session « La revue de code : c’est agile, c’est lean, c’est indispensable ! » présentée à Agile France et Agile Tour en 2010.
Après avoir répondu aux idées reçues sur la revue de code et avoir montré combien une revue de code systématique soutient une démarche agile et lean, cette présentation se focalise sur la mise en place de la revue de code comme étape incontournable du processus de développement.
Nous évoquerons les bonnes pratiques, les difficultés à la mise en place, les pièges à éviter et aussi les outils qui facilitent la revue de code. Une grande partie de la présentation sera dédiée à plusieurs démonstrations, exemples et retours d’expérience.
Votre projet marche, mais c'est le chaos. Comment arrêter de dépendre de ces "héros" sur qui tout repose ?
Présentation vidéo : https://youtu.be/aClcNdOqtsE
Suite à ma lecture de "The Software Craftsman" de Sandro Mancuso, je présente ce qu'est le Software Craftsmanship.
Présentation visible sur YouTube : https://youtu.be/RW0-QIJttBM
Introduction aux spécifications exécutables (dit aussi atdd, bdd)Jean-Pierre Lambert
Comment s'assurer que tout le monde parle la même langue dans l'équipe ? Et ainsi éviter les retours de recette ?
Utiliser des spécifications exécutables, ou ses cousins le ATDD (Acceptance Test Driven Development) et le BDD (Behavior Driven Development), est un élément de réponse particulièrement pertinent. Cette méthode est également un point d'entrée puissant vers une stratégie d'automatisation des tests.
Dans cette présentation vous découvrirez les tenants et les aboutissants de cette méthode, et repartirez les poches remplies de conseils de mise en place.
Deployer en continu, Benoît Lafontaine, USIEVENT 2013Benoît Lafontaine
Presentation played at USIEVENT 2013, see the presentation on youtube: http://www.youtube.com/watch?v=UcDtH5s406M&feature=share&list=PLyzb9DL11tdZBlz6nY8TZxMcqVf04K5wY
La revue de code : agile, lean, indispensable !Lucian Precup
Présentation faite à Agile France en 2010 :
La revue de code : agile, lean, indispensable !
Alors que l’intégration continue ou les tests unitaires commencent à rentrer dans les "standards", la revue de code est souvent considérée comme optionnelle. Pourtant, les avantages d’une revue de code systématique sont multiples : détection des anomalies très tôt dans le cycle de développement, formation des membres de l’équipe, partage de la connaissance, meilleures solutions techniques par la conjonction des perspectives développeur/examinateur.
Cette présentation mettra en évidence les avantages de la revue du code en répondant aux idées reçues comme "la revue du code augmente la durée des développements", ou "nos développeurs sont très bons, ils n’ont pas besoin de revue de code" ou encore "il n’y a personne dans l’équipe qui puisse examiner mon code car je suis le seul à connaître Bash et Ant". En évoquant la revue de code dans l’univers open source, les différents moyens de la mettre en œuvre, ses compléments, les différents outils ; et terminant par une démonstration concrète en utilisant Eclipse, Bugzilla et Mylyn, cette présentation vous convaincra de mettre en place la revue de code systématique dans votre équipe sans attendre.
Déroulement :
1/ Avantages
2/ Idées reçues
3/ La revue de code dans l’univers open-source : de la revue du patch par le committeur aux procédures très élaborées comme celles de Mozilla Developer Center.
4/ Moyens de mise en œuvre : à partir de quelle taille des projets, par qui, comment, avant l’intégration ou après, ...
5/ Les compléments de la revue du code : analyse de la qualité du code, scripts pour les normes internes, ...
6/ Comparaison avec d’autres techniques : pair programming, ...
7/ Outils et intégration avec les autres outils de développement ou de gestion du cycle de vie (intégration continue, gestion des anomalies, ...)
8/ Démonstration des avantages sur un exemple concret en utilisant Eclipse, Bugzilla et Mylyn comme outils.
9/ Conclusion : comment la revue de code supporte une démarche agile et lean
Votre boss doute de la pertinence des revues de code ? Vous avez essayé mais ça n'a pas marché ?
Joffrey et Nicolas vous donneront les clés pour comprendre comment conduire des revues de codes efficaces et pertinentes.
Ils parleront de leurs expériences au sein de leurs équipes ainsi que des pièges à éviter.
Si les revues de code attisent votre curiosité, cette conférence est faite pour vous !
D1 - Un développeur est-il un numéro, un coût journalier ou un artiste ?XP Day CH
Le métier et le rôle du développeur ont fortement évolués au cours des 10 dernières années du fait notamment de l'adoption massive des méthodologies agiles. De manière ludique, cette session mettra en lumière cette évolution et ces enjeux.
Freddy Mallet
Faire la conception en équipe sans architecte, non mais allô quoi ?Ly-Jia Goldstein
Talk présenté :
- au BreizhCamp (http://lyjia.net/breizhcamp-slides-de-ma-presentation/)
- Agile Tour Montpellier
"Les équipes s'auto-organisent afin de faire émerger les meilleures architectures, spécifications et conceptions." C'est sur ce principe du manifeste agile que se base la notion d'équipe auto-organisée de Scrum. En pratique, beaucoup d'entreprises qui ont mis en place Scrum gardent leurs architectes dans leurs tours d'ivoire.
C'est une décision normale car peut-on imaginer qu'une équipe puisse concevoir une architecture ? Et puis soyons sérieux, est-ce qu'un design par des développeurs pourrait être meilleur que celui d'un architecte ? Qu'allez-vous faire de vos architectes sinon ?
À travers un retour d'expérience, nous verrons qu'effectivement confier l'architecture aux équipes n'est pas rentable si ce n'est pas fait intelligemment. En revanche, si la conception en équipe est bien maîtrisée, les bénéfices iront bien au-delà du cercle des développeurs.
Nous développons et livrons du logiciel plus vite que jamais, ou du moins nous le souhaitons. De nombreux obstacles empêchent généralement cet objectif : ségrégations technologiques, méthodes de travail, dispersion des équipes, manque de traçabilité, etc. Cette présentation est 100% « No Silver Bullet », toutefois vous y trouverez des réponses concrètes à vos problèmes.
Par Michel Perfetti. Michel Perfetti travaille depuis 2006 sur les problématiques d'industrialisation sur la plateforme Microsoft. Il est MVP depuis 2006, MVP Visual Studio ALM depuis 2010 et ALM Rangers. Michel est également Manager du pôle ALM chez Cellenza. Il intervient en tant que consultant sur des problématiques d'architecture ou développement ainsi que des problématiques liées aux méthodologies de travail et à l'Agilité.
La vidéo de la conférence est à retrouver sur : http://www.xebicon.fr/programme.html
La génération de code utilisée à bonne escient et un excellent moyen d’augmenter considérablement la productivité des développeurs dans de nombreux scenarii, particulièrement (mais pas uniquement) celui des applications de gestion orientée données. Si cette approche montrait vite ses limites à une époque, les choses ont bien évolué avec les versions récentes de C# ou VB.NET. Microsoft propose différents outils pour générer du code. Nous aborderons les T4 et les NuGet dans le cadre de cette session. En plus de la génération de code, la meta-programmation est englobe également l’analyse du code. Nous parlerons donc de Roslyn, l’API de Microsoft répondant à ce besoin. Dans le cadre de cette session, nous verrons comment la meta-programmation peut réellement révolutionner le travail d’une partie des développeurs, accroître de manière considérable la productivité des développeurs et réduire très fortement le risque sur les projets.
La relecture de code : avant tout des pratiquesEric SIBER
Quelle est l'utilité de la relecture de code ? Bonnes pratiques, mauvaises pratiques, comment s'y prendre pour mener cette tâche à bien malgré les obstacles organisationnels ?
Cette session vise à sensibiliser les participants à la problématique de relecture de code. Souvent ce sont les outils qui font le buzz, reléguant les pratiques et leur adoption au second plan. Loin des effets whaou de la démo d'un outil, je souhaite vous sensibiliser au pourquoi et comment, tout en illustrant par des pratiques : de la plus élémentaire à la plus tendance. Des pistes seront données à l'audience pour mettre en place ou renforcer la démarche qualité sur le terrain, ainsi que les références aux outils qui s'inscrirons dans ces pratiques.
A l'image du premier principe du manifeste agile (Les individus et leurs interactions plus que les processus et les outils), la présentation sera donc largement tournée sur l'humain, le relationnel, elle ne détaille ni ne fait la promotion d'un processus ou d'un outil donné de relecture de code (qui seront néanmoins mentionnés).
Comment choisir un workflow Git adapté à votre équipe? Comment améliorer votre productivité tout en réduisant les frictions au sein de votre équipe? Quelles sont les pratiques utilisées dans l’industrie et les équipes agiles? Comment utilisons-nous Git au sein d’Atlassian?
Comme vous avez pu l’entendre, Git offre de nombreuses fonctionnalités intéressantes, et a acquis un incroyable succès dans l’industrie au sens large. Pourtant, l’adoption de Git au sein de votre entreprise peut être intimidant. Le “Git Ready” webinar a pour objectif de répondre à ces questions et plus.
Nous abordons:
* Les modèles de collaboration disponibles lors de l’utilisation d’un système de contrôle de version distribué comme Git
* Les modèles de branche qui favorisent le renforcement du développement parallèle
* Les “best practice” émergentes et les choix pouvant être adoptées en toute sécurité lors de la migration vers Git
Nous abordons aussi comment l’Intégration Continue change du tout au tout lorsque votre équipe embrasse Git.
Développer en mode Kick-Ass permet de vraiment faire les choses.
Dans cette présentation je montre comment:
- nous utilisons les Pull Requests pour la qualité du code
- collaborer rapidement pour développer vos idées
- éviter les meetings pour être productif
- raccourcir les boucles de retour pour échouer plus rapidement
- raccourcir vos cycles de livraison
- et travailler ensemble à travers différents continents.
Cela peut fonctionner aussi dans votre entreprise.
Pourquoi et comment nous relisons ensemble tout le code que nous produisons - retour d'expérience du WebCenter AXA sur la revue de code, accompagnés par Octo.
Développer en mode Kick-Ass permet de vraiment faire les choses.
Dans cette présentation je montre comment:
- nous utilisons les Pull Requests pour la qualité du code
- collaborer rapidement pour développer vos idées
- éviter les meetings pour être productif
- raccourcir les boucles de retour pour échouer plus rapidement
- raccourcir vos cycles de livraison
- et travailler ensemble à travers différents continents.
Cela peut fonctionner aussi dans votre entreprise.
Mise en place de bonnes pratiques (Scrum et php) au sein de projets existantsNicolas De Boose
Retour d'expérience technique et organisationnelle . Au menu :
- Passage à scrum: Les difficultés et solutions
- Code legacy: Du néan à l'industrialisation
Client complex, très ractif au marché, évolution constante des specs.
Incertitude certaine !
Contenu connexe
Similaire à Agile France - Software Craftsmanship - Juin 2019
Votre boss doute de la pertinence des revues de code ? Vous avez essayé mais ça n'a pas marché ?
Joffrey et Nicolas vous donneront les clés pour comprendre comment conduire des revues de codes efficaces et pertinentes.
Ils parleront de leurs expériences au sein de leurs équipes ainsi que des pièges à éviter.
Si les revues de code attisent votre curiosité, cette conférence est faite pour vous !
D1 - Un développeur est-il un numéro, un coût journalier ou un artiste ?XP Day CH
Le métier et le rôle du développeur ont fortement évolués au cours des 10 dernières années du fait notamment de l'adoption massive des méthodologies agiles. De manière ludique, cette session mettra en lumière cette évolution et ces enjeux.
Freddy Mallet
Faire la conception en équipe sans architecte, non mais allô quoi ?Ly-Jia Goldstein
Talk présenté :
- au BreizhCamp (http://lyjia.net/breizhcamp-slides-de-ma-presentation/)
- Agile Tour Montpellier
"Les équipes s'auto-organisent afin de faire émerger les meilleures architectures, spécifications et conceptions." C'est sur ce principe du manifeste agile que se base la notion d'équipe auto-organisée de Scrum. En pratique, beaucoup d'entreprises qui ont mis en place Scrum gardent leurs architectes dans leurs tours d'ivoire.
C'est une décision normale car peut-on imaginer qu'une équipe puisse concevoir une architecture ? Et puis soyons sérieux, est-ce qu'un design par des développeurs pourrait être meilleur que celui d'un architecte ? Qu'allez-vous faire de vos architectes sinon ?
À travers un retour d'expérience, nous verrons qu'effectivement confier l'architecture aux équipes n'est pas rentable si ce n'est pas fait intelligemment. En revanche, si la conception en équipe est bien maîtrisée, les bénéfices iront bien au-delà du cercle des développeurs.
Nous développons et livrons du logiciel plus vite que jamais, ou du moins nous le souhaitons. De nombreux obstacles empêchent généralement cet objectif : ségrégations technologiques, méthodes de travail, dispersion des équipes, manque de traçabilité, etc. Cette présentation est 100% « No Silver Bullet », toutefois vous y trouverez des réponses concrètes à vos problèmes.
Par Michel Perfetti. Michel Perfetti travaille depuis 2006 sur les problématiques d'industrialisation sur la plateforme Microsoft. Il est MVP depuis 2006, MVP Visual Studio ALM depuis 2010 et ALM Rangers. Michel est également Manager du pôle ALM chez Cellenza. Il intervient en tant que consultant sur des problématiques d'architecture ou développement ainsi que des problématiques liées aux méthodologies de travail et à l'Agilité.
La vidéo de la conférence est à retrouver sur : http://www.xebicon.fr/programme.html
La génération de code utilisée à bonne escient et un excellent moyen d’augmenter considérablement la productivité des développeurs dans de nombreux scenarii, particulièrement (mais pas uniquement) celui des applications de gestion orientée données. Si cette approche montrait vite ses limites à une époque, les choses ont bien évolué avec les versions récentes de C# ou VB.NET. Microsoft propose différents outils pour générer du code. Nous aborderons les T4 et les NuGet dans le cadre de cette session. En plus de la génération de code, la meta-programmation est englobe également l’analyse du code. Nous parlerons donc de Roslyn, l’API de Microsoft répondant à ce besoin. Dans le cadre de cette session, nous verrons comment la meta-programmation peut réellement révolutionner le travail d’une partie des développeurs, accroître de manière considérable la productivité des développeurs et réduire très fortement le risque sur les projets.
La relecture de code : avant tout des pratiquesEric SIBER
Quelle est l'utilité de la relecture de code ? Bonnes pratiques, mauvaises pratiques, comment s'y prendre pour mener cette tâche à bien malgré les obstacles organisationnels ?
Cette session vise à sensibiliser les participants à la problématique de relecture de code. Souvent ce sont les outils qui font le buzz, reléguant les pratiques et leur adoption au second plan. Loin des effets whaou de la démo d'un outil, je souhaite vous sensibiliser au pourquoi et comment, tout en illustrant par des pratiques : de la plus élémentaire à la plus tendance. Des pistes seront données à l'audience pour mettre en place ou renforcer la démarche qualité sur le terrain, ainsi que les références aux outils qui s'inscrirons dans ces pratiques.
A l'image du premier principe du manifeste agile (Les individus et leurs interactions plus que les processus et les outils), la présentation sera donc largement tournée sur l'humain, le relationnel, elle ne détaille ni ne fait la promotion d'un processus ou d'un outil donné de relecture de code (qui seront néanmoins mentionnés).
Comment choisir un workflow Git adapté à votre équipe? Comment améliorer votre productivité tout en réduisant les frictions au sein de votre équipe? Quelles sont les pratiques utilisées dans l’industrie et les équipes agiles? Comment utilisons-nous Git au sein d’Atlassian?
Comme vous avez pu l’entendre, Git offre de nombreuses fonctionnalités intéressantes, et a acquis un incroyable succès dans l’industrie au sens large. Pourtant, l’adoption de Git au sein de votre entreprise peut être intimidant. Le “Git Ready” webinar a pour objectif de répondre à ces questions et plus.
Nous abordons:
* Les modèles de collaboration disponibles lors de l’utilisation d’un système de contrôle de version distribué comme Git
* Les modèles de branche qui favorisent le renforcement du développement parallèle
* Les “best practice” émergentes et les choix pouvant être adoptées en toute sécurité lors de la migration vers Git
Nous abordons aussi comment l’Intégration Continue change du tout au tout lorsque votre équipe embrasse Git.
Développer en mode Kick-Ass permet de vraiment faire les choses.
Dans cette présentation je montre comment:
- nous utilisons les Pull Requests pour la qualité du code
- collaborer rapidement pour développer vos idées
- éviter les meetings pour être productif
- raccourcir les boucles de retour pour échouer plus rapidement
- raccourcir vos cycles de livraison
- et travailler ensemble à travers différents continents.
Cela peut fonctionner aussi dans votre entreprise.
Pourquoi et comment nous relisons ensemble tout le code que nous produisons - retour d'expérience du WebCenter AXA sur la revue de code, accompagnés par Octo.
Développer en mode Kick-Ass permet de vraiment faire les choses.
Dans cette présentation je montre comment:
- nous utilisons les Pull Requests pour la qualité du code
- collaborer rapidement pour développer vos idées
- éviter les meetings pour être productif
- raccourcir les boucles de retour pour échouer plus rapidement
- raccourcir vos cycles de livraison
- et travailler ensemble à travers différents continents.
Cela peut fonctionner aussi dans votre entreprise.
Mise en place de bonnes pratiques (Scrum et php) au sein de projets existantsNicolas De Boose
Retour d'expérience technique et organisationnelle . Au menu :
- Passage à scrum: Les difficultés et solutions
- Code legacy: Du néan à l'industrialisation
Client complex, très ractif au marché, évolution constante des specs.
Incertitude certaine !
Similaire à Agile France - Software Craftsmanship - Juin 2019 (20)
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
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)