Le jour où tu dois passer à l’échelle, selon comment tu as fait les choses, c’est plus ou moins simple.
Le pire des trucs à faire : stocker des états sur ton serveur d’application.
Y’en a 11 autres dont on parle avec Christophe et c’est ici :
Les 12 facteurs : https://12factor.net/
Le site de Christophe : http://lydra.fr
Se former dans la maison des compagnons : https://maison.artisandeveloppeur.fr
Rejoindre la communauté des artisans développeurs :
https://artisandeveloppeur.fr
En 2001, je faisais parti des premiers contributeurs à déclarer leurs impôts via Internet. A l’époque il y avait une prime de 20€ si tu utilisais ce moyen. Aujourd’hui c’est en train de devenir obligatoire un peu partout. Et ce sera bientôt sanctionné de ne pas le faire…
J’ai pensé à ça en améliorant le projet de bac à sable de refactoring. Par définition, c’est un projet ‘boule de boue’. Donc il n’y a pas de test, ni d’intégration continue. Normal pour une app legacy… Et quand je dis améliorer, je veux dire empirer les choses ! 😈
Du coup à la première pull-request, je vois un joli message de github me suggérant fortement d’intégrer un service d’intégration continue. 😍🤩
Là une petite larme me vient aux yeux et je constate alors avec satisfaction que ça y est ! L’intégration continue est entrée dans les mœurs. Ce n’est plus une pratique d’extra-terrestre, ni même une technique avancée. C’est devenu normal. C’est le fait de ne pas en avoir qui est devenu anormal.
Combien de temps faudra-t-il pour arriver à la même considération pour les autres pratiques comme le TDD (Test Driven Development) ?
J’étais hier à Agile Grenoble et lors de la session de Xavier Nopre sur le TDD, je constate avec plaisir que les gens convaincus par la nécessité d’écrire des tests automatiques sont maintenant majoritaires. Mais quand il s’agit de mettre en oeuvre, il n’y plus grand monde.
Cela donne une idée du curseur d’avancement dans les consciences et le chemin qui reste à parcourir pour diffuser les bonnes pratiques.
Car je peux maintenant l’affirmer sereinement : sans TDD, point d’agilité. Et c’est d’ailleurs tout le point de Xavier dans sa conf.
Sans TDD, je n’ai pas de tests efficaces.
Sans tests efficaces, je ne refactore pas mon code car il me fait peur.
Si j’ai peur de mon code, j’en perds la maîtrise.
Et sans maîtrise je ne peux pas accélérer.
Faire de l’agilité avec des cycles courts sans TDD, c’est comme rouler sur un circuit de formule 1 avec des pneus lisses. Ca finit forcément mal.
Le simple fait que tu sois en train de lire ce message est déjà encourageant. Nous ne sommes plus une secte bizarre de développeurs extrémistes. Notre art devient la norme. Et je ne peux que m’en réjouir car il est synonyme d’épanouïssement pour ses adeptes et de compétitivité pour leurs employeurs.
L’eXtreme Programming est de moins en moins eXtreme et devient le State-Of-Art Programming.
Encore faut-il savoir le faire. La bonne nouvelle c’est que ce ne sont pas les ressources qui manquent !
Rien que sur le podcast, tu trouveras ces épisodes qui parlent de comment l’adopter :
C’est aussi tout l’objet du cursus Artisan Développeur de la maison des compagnons : passer d’un code legacy à un code de compétition pour passer d’un quotidien ennuyeux et stressant à un quotidien épanouïssant. 😃
On arrête pas de parler de TDD tous les jours … En parler c’est bien mais faut s’y mettre ! Comme dirait Mc Cain:
C’est ceux qui en parle le plus, qui en mange le moins …
Et si on peut même faire du Cobol en TDD, y’a pas de raison qu’on ne puisse pas le faire pour du JS dans un projet Symfony. Ça va être pour les tests unitaires.
Jean Pierre Lambert et Michael Azerhad ne sont pas d’accord sur cette question :
Pour Michael, une équipe sans tech lead va forcement dans le mur.
Viens écouter notre échange ici :
Et toi qu’en penses-tu ?
L’échange initial avec Jean-Pierre : https://artisandeveloppeur.fr/le-role-de-tech-lead-est-il-un-anti-pattern-avec-jean-pierre-lambert/
Le profil linkedin de Michael : https://www.linkedin.com/in/micha%C3%ABl-azerhad-9058a044/
L’entreprise de Michael : http://wealcomecompany.com
Se former dans la maison des compagnons : https://maison.artisandeveloppeur.fr
Rejoindre la communauté des artisans développeurs :
https://artisandeveloppeur.fr
A propos de l’auteur : Si Nicolas Bouteillier était une liste de tag: développeur, technicien, artisan, entrepreneur, geek.
Nicolas est développeur depuis 2002, il a accompagné en mode lean startup plusieurs démarrages de projets, gérant de sa SARL, auto-entrepreneur, salarié,
c’est un touche à tout riche d’expériences variées qui a accosté sur les rives de l’agilité sans jamais quitter le monde entrepreneurial.
Dans l’épisode du jour, on va faire original et parler du TDD !
En particulier qu’est-ce qui le rend si difficile à adopter.
Quelles sont les (fausses) idées pré-conçues sur cette pratique ?
Viens écouter mon échange avec Nicolas Verinaud.
L’article mentionné : http://geepawhill.org/tdd-and-the-lump-of-coding-fallacy/
A propos de Nicolas :
http://ryfacto.fr/
https://www.linkedin.com/in/nicolas-verinaud-7829881a/
https://twitter.com/nverinaud
Se former dans la maison des compagnons : https://maison.artisandeveloppeur.fr/
Rejoindre la communauté des artisans développeurs :
https://artisandeveloppeur.fr/
Après avoir passé des mois à acquérir la compétence, des années à la pratiquer, je teste de re-coder sans TDD. (explosif)
Et Guillaume Vincent a joué à ça aussi.
Alors on en parle, cet échange est vraiment riche si tu as envie de découvrir l’autre côté du mirroir.
Et là tu découvres ce moment où ça devient douloureux de ne plus coder en TDD… Car finalement tu testes de toute façon… Mais quand c’est manuel, c’est pas pareil…
En plus de ne pas ressentir de plaisir, la vitesse de développement baisse en quelques heures.
Un échange surprenant que je t’invite à découvrir ici:
Le github de Vincent : https://github.com/guillaumevincent
Pour rejoindre la communauté : https://artisandeveloppeur.fr
Se former dans la maison des compagnons : https://maison.artisandeveloppeur.fr
Michaël a lancé la bataille avec un billet dans lequel il met en avant les biais de cette pratique. Mais Jean-Pierre n’est pas d’accord. Alors, est-ce une question de contexte ?
Est-ce une différence de compréhension du concept de vélocité ?
Est-ce une question de DOD ?
Et si c’était juste une question d’adhérer aux valeurs agiles, je veux dire pour de vrai..?
Comment on gère les différences de niveau entre développeurs ?
Quel est le rôle du SCRUM Master ou du Tech Lead ?
Viens écouter les points de vue qui s’affrontent dans cet épisode spécial Battle #1 !
La vision de Jean-Pierre : https://www.youtube.com/watch?v=NZxcqei5qIE
Le point de vue de Michaël : https://medium.com/wealcomecompany/le-poker-planning-une-bonne-chose-hold-on-b35531a61e7b
Je constate qu’il faut souvent avoir souffert avant d’en arriver à se poser des questions sur les bonnes pratiques…
En particulier le TDD est de loin la pratique la plus difficile à adopter.
Certains même remettent en question son utilité ! 😱
Viens écouter le chemin que Nicolas a emprunté : pourquoi il est y arrivé, comment il a franchi les moments difficiles.
A propos de Nicolas :
http://ryfacto.fr/
https://www.linkedin.com/in/nicolas-verinaud-7829881a/
https://twitter.com/nverinaud
Pour découvrir la formation : https://maison.artisandeveloppeur.fr/ranger-chaque-chose-a-sa-juste-place?coupon=KICKSTART
Pour rejoindra la communauté des artisans développeurs :
https://artisandeveloppeur.fr/
Tu changes de framework front d’angular vers react ?
Ou l’inverse (non sérieux ?)
Viens écouter cet épisode avec Guillaume Vincent qui nous partage son expérience chez Red Hat.
Découvrir Guillaume : https://guillaumevincent.com/
Pour découvrir la formation : https://maison.artisandeveloppeur.fr/ranger-chaque-chose-a-sa-juste-place?coupon=KICKSTART
Rejoindre la communauté des artisans développeurs : https://artisandeveloppeur.fr
