TDD or not TDD ? On a remis ça avec Kevin

Oups, je l’ai encore fait.

J’ai posté un truc pour chauffer mon ami Kevin (que j’apprécie vraiment, c’est pas juste une tournure de phrase). Et c’est encore parti en sucette.

Il a répondu via un post, et là, c’est parti en bataille rangée.

Si tu regardes bien, chacun a rallié son camp : les pro-TDD VS les on-peut-faire-sans-TDD.

Au-delà des tacles biens sentis, il faut dire qu’il a une sacré répartie Kevin, on trouve des questions et remarques qui m’ont fait réfléchir. Autant faire quelque chose d’utile de tout ce bruit.

“Si en 4h sans TDD tu as des régressions en cascade : change de métier.”

Uppercut direct au foie. Il m’a fallu un petit moment pour l’encaisser celle-là.

Suis-je devenu mauvais ?
Ai-je été bon un jour ?
Qu’est-ce qui fait que je reste convaincu de ma démarche ?

J’avoue que le doute s’est instillé.

Et c’est un commentaire qui m’a donné la réponse : “Je pars du principe que le code que j’écris marche et je vérifie ensuite”.

Alors que pour moi c’est tout l’inverse : je pars du principe que je vais faire des erreurs. Du coup je code d’une manière qui me rassure. Et le TDD rassure beaucoup.
Ce n’est pas sa seule vertu, et ce serait dommage de réduire le TDD à des tests, et en même temps, c’est le cœur de la démarche. Parler de TDD sans test est juste un non sens.
Car les tests rassurent : que le code marche, que je vais pouvoir le faire évoluer, que je suis sur la bonne voie vers l’objectif.

Alors oui, quand j’étais jeune, mon cerveau était capable de coder des heures entières sans le moindre de test, mais la charge cognitive n’était pas la même. 

Coder sans TDD, c’est juste super fatigant : le TDD est au développement ce que le GTD est à la productivité. Un outil pour baisser la charge mentale et garder son énergie pour ce qui permet de créer de la valeur. 

Est-ce que tu apportes plus de valeur en te demandant ce que tu vas ou pas casser, comment tu vas designer ci ou ça, ou bien en créant les fonctionnalités qui vont ravir tes utilisateurs ?
Et bien sûr que tu peux faire les deux. Mais je suis convaincu que l’énergie se dissipe.

Alors est-ce que je n’en suis plus capable ?
Est-ce que je suis devenu mauvais parce que je n’anticipe pas les régressions que je pourrais causer ou que je préfère me laisser guider par les tests pour concevoir mon app ?

Peut-être. 

Ou alors peut-être que je n’en n’ai juste plus envie parce que j’ai trouvé une autre manière de faire beaucoup plus efficace et satisfaisante. Difficile de faire la part des choses. En tout cas, je pense que je suis devenu inadapté pour travailler sans.

D’ailleurs j’adorerais bosser sur un gros chantier de refactoring pour tester l’expérience. Et si tu veux connaître la démarche que j’applique pour aider mes clients à reprendre en main leur legacy, c’est ici et c’est gratuit.

“Twitter, instagram bossent sans TDD”

Alors dans la série des arguments foireux, celui-là tient la palme.
Depuis quand le nombre ou la taille est un argument recevable ?
On se fait un rappel historique ? Certains dictateurs ont été élus par suffrage…

Ensuite, mentionner des boites qui ont des moyens quasiment illimités est-il bien sérieux ?
J’ai eu le plaisir d’inviter le lead dev android d’ubber sur le podcast. Ils ont réécrit l’app 3 fois, tous les deux à trois ans environ.

Il faut être lucide : peu de sociétés ont autant de moyens. Dans mon quotidien, je vois surtout des start-up qui calent au moment de monter en pression et qui n’arrivent pas à financer un re-développement. Les devs restent englués dans un code qui les engloutit petit à petit et le business avec.

Peut-être que les start-ups ont plus de moyens outre atlantique, c’est bien possible. Mais ce n’est pas le reflet de ce que je vois en France. 

Une question d’efficacité

On m’a reproché de parler de régression en cascade pour un pauvre changement de champ de base qui générait une régression non anticipée.

Comme si j’en faisais des caisses pour pas grand chose. Ok je suis Marseillais dans l’âme et à moitié Italien. Mais il y a plus que ça.

Je pense que j’ai développé une sensibilité élevée à la perte d’efficacité.
Du coup, je me suis demandé comment je pourrais objectiver ce ressenti :

  • Je me rends compte que quand je dois ouvrir l’app à chaque modification pour me rassurer, je commence à être tendu.
  • Quand l’idée d’implémenter un algo basique me rebute, c’est que je suis sur une mauvaise trajectoire.
  • Le pire : quand je ne me rends pas compte que je casse quelque chose au moment de coder. Là, je me tends beaucoup. Entendre par là : je lance l’app en pensant que ça va marcher et ce n’est pas le cas.

Alors je sais que pour beaucoup de développeurs ces choses sont banales. Pourquoi en faire tout un plat ?

Parce que c’est désagréable ! 
J’aime bien me savonner avec un gant doux et moelleux. A la rigueur un gant de crin peut avoir des vertus. Mais la brosse métallique, non merci.

Bien sûr qu’on peut développer de grosses apps sans TDD, des tas de développeurs le font au quotidien.

Mais est-ce efficace ?

La seule vraie question qui m’échappe est plutôt l’inverse : pourquoi faire sans ?

Et si Kevin avait (un peu) raison ?

L’expérience n’a pas été vaine. 

Je remets un peu de contexte : avec 2 amis, on se chauffe pour faire un bot telegram dans la crypto. Je suis super excité par le projet, mais…

Je ne connais ni le langage, ni la stack. J’ai toujours bossé à l’intérieur de la blockchain en écrivant des smart contracts, très peu de l’extérieur pour les opérer avec un bot.

Je n’ai jamais fait de bot telegram.

Le projet est plus un concept qu’un truc défini : on a une direction, quelques API à intégrer et roule.

Autant dire que le product-market-investors fit n’est pas encore là.

Pourtant j’ai très envie de poser quelque chose rapidement. Et je dois ingérer beaucoup d’informations nouvelles en peu de temps. Alors je fonce et je code un bot dans un fichier à plat de quelques centaines de lignes. 

0 design.

0 tests.

Tout ça donne une orgie de code sans laquelle toutes les couches se mélangent gaiement : la base de données échange directement avec la logique de génération de wallet. L’affichage se fait à même le traitement de données. La gestion d’erreur se mélange avec l’ihm.

Une hérésie.

Et c’était très bien : j’ai pu tester l’idée, me rassurer sur la faisabilité. Voir quelque chose qui marche donne envie de faire un pas de plus ce qui est motivant pour l’équipe.

Mais je tremble déjà à l’idée de mettre en prod en l’état : on parle de quelque chose qui pourrait manipuler des millions. Ça peut aller très vite dans la crypto. Et je ne serais pas serein de faire ça sans savoir que je vais pouvoir continuer à faire évoluer l’app tranquillement. Certains savent faire ça sans TDD. Moi j’en ai besoin.

Donc si aller droit au but et explorer a été vertueux pour découvrir, je sens que je perds maintenant en efficacité et qu’il est temps d’installer Chai.

En plus, ça va me faire du legacy à reprendre !

Tu veux dynamiter ton legacy sans te prendre la tête : clique ici.

Alors, est-ce que Kevin a raison ? 

Disons qu’il n’a pas complètement tort. Si j’avais ralenti le dev du prototype, peut-être que je serais encore à réfléchir à comment architecturer la couche métier et le momentum entre nous serait passé. Peut-être.

Mais attention : le monstre spaghetti grandit vite et peu de développeurs s’en rendent compte à temps. Considérer qu’on pourra tout jeter et refaire ne me semble pas très responsable. C’est peut-être moi qui en fait tout un plat. Après tout, si ce n’était que de l’argent, pourquoi pas. Mais je parle aussi de bien être dans son travail. 

On se le fait quand cet octogone ?

Ca n’apporterait pas grand chose au débat, mais ça ferait certainement une belle hype ! 🚀

On ferait des vidéos youtube de nos entraînements, on continuerait à se mettre dessus sur LinkedIn et on irait boire des bières après. ❤️

Code Legacy : Le mignon compagnon devenu monstre

Le Legacy peut devenir un monstre vorace !

Il était une fois, dans une petite start-up en plein essor, un jeune développeur nommé Léo. Lors de son premier jour, on lui présenta son compagnon : un petit bout de code, tout mignon, tout simple, destiné à être le cœur de leur nouvelle application. Léo était ravi. Il le nourrissait régulièrement de nouvelles fonctionnalités, et le code grandissait, s’épanouissait.

Continuer la lecture de « Code Legacy : Le mignon compagnon devenu monstre »

Identifier le code mort : Pourquoi et comment s’en débarrasser ?

Si tu es là, c’est que tu as peut-être déjà croisé ce fameux « code mort » qui traîne dans les recoins sombres de ton projet. Et si tu n’as pas encore osé le supprimer, tu n’es pas seul. Beaucoup d’entre nous hésitent, par peur de casser quelque chose. Mais laisse-moi te dire : un bon nettoyage n’a jamais fait de mal à personne ! Alors, comment repérer ce code inutile ? C’est parti !

Nettoyer son code mort, c’est comme élaguer un arbre
Continuer la lecture de « Identifier le code mort : Pourquoi et comment s’en débarrasser ? »

Refactoring de code : le guide pour bien débuter

Le refactoring est un travail continue de patience

Salut à toi, jeune padawan du code ! Si tu es ici, c’est que tu as entendu parler du refactoring de code et que tu veux te lancer.

Bravo ! Tu es sur la bonne voie.

Le refactoring, c’est un peu comme apprendre à entretenir ton vélo pour qu’il roule toujours bien. Alors, enfile tes gants de mécano, et plongeons ensemble dans ce guide pratique.

Continuer la lecture de « Refactoring de code : le guide pour bien débuter »

Négocier le craft comme un pro du FBI

Tu aimerais embarquer ton équipe dans le software craftsmanship, mais tu sens des réticences ? Cette mini série est faite pour toi.

Je m’inspire du livre de Chris Voss, Ne coupez jamais la poire en deux, pour te proposer des exercices concrets afin d’influencer ton équipe.

Et si tu veux aller plus loin, rejoins moi dans TCaftLab, c’est gratuit : https://systeme.artisandeveloppeur.fr/tcraftlab

Software Craftsmanship ou la déchéance ?

Suite aux attaques en règle de Kevin et le drama qui s’en est suivi, j’ai beaucoup réfléchi car j’entendais une petite musique qui me gênait.
Dans mon enthousiasme, et même une forme de ferveur, de défendre une cause noble à mes yeux, le bonheur des développeurs, j’ai eu l’impression de franchir une ligne rouge.
Alors je me suis remis en question.

Développeur perdu
Continuer la lecture de « Software Craftsmanship ou la déchéance ? »

Software craftsmanship & TDD drama

Comment en est-on arrivé là ?

C’est une bonne question. Intéressant de voir comment les choses dérapent, un peu au début, beaucoup ensuite ! 

Tout commence avec un post un brin provocateur de Kevin sur linkedin : 

https://www.linkedin.com/feed/update/urn:li:activity:6943520332855054336/

Continuer la lecture de « Software craftsmanship & TDD drama »

Software craftsmanship : une question de compromis

Aujourd’hui, j’ai du écrire un code affreux. 😭
Alors j’ai besoin d’écrire cet article pour m’excuser.

Photo by Caleb Jones on Unsplash

Non en fait j’assume. Et je pense que c’est important de t’expliquer ce qui s’est passé.

Continuer la lecture de « Software craftsmanship : une question de compromis »

Pair Programming VS Mob Programming

Cet article est rédigé en paire avec Hadrien. On s’est dit que c’était bien d’illustrer le concept par la pratique !

Photo de Tudor Baciu sur Unsplash

C’est quoi le pair-programming ?

Le pair programming, ou travail en binôme, est une pratique qui consiste à travailler à deux en même temps sur une même tâche de développement.
En gros, au lieu de bosser à un seul cerveau, tu bosses à deux.

Tu trouveras ici un article assez complet sur le pair-programming dans lequel tu verras comment le pratiquer et le mettre en oeuvre. Si tu n’est pas au clair avec cette pratique, je te conseille de commencer par là !

C’est quoi le mob-programming ?

“Un mob, c’est réunir toutes les personnes qui sont nécessaires au succès d’une tâche autour d’un seul poste de travail.”

Piqué par Hadrien à Woody Zuill

Bon, dit comme ça, c’est abstrait, mais concrètement, ça donne quoi ?
Si tu as connu les tasks forces, ça y ressemble !

Tu sais, le moment où c’est la m$#§e sur le projet, que la deadline arrive et qu’on met tout le monde dans une ‘war room’ pour sauver le monde (et le projet).

Ben c’est la même chose, mais avant que ce soit le bordel.

Concrètement, tu mets les développeurs du projet, et tous ceux qui sont utiles dans une même salle, en même temps, devant un seul écran.

La différence avec le pair-programming: ben c’est juste le nombre.
Au lieu d’être 2, tu peux être 3, 4, 5 ou plus si affinité.

Bon en vrai, au-delà de 6, ça va être compliqué à tenir dans le temps. Si tu as besoin de plus d’une pizza (format américain) pour nourrir ton équipe c’est qu’il est temps de la diviser.

Et finalement cette toute petite différence, tel un battement d’aile de papillon, engendre de grandes différences.

C’est ce qu’on va voir maintenant.

Continuer la lecture de « Pair Programming VS Mob Programming »

Pair programming : le guide ultime

Qu’est-ce que le pair programming ?

Le pair programming, ou travail en binôme, est une pratique qui consiste à travailler à deux en même temps sur une même tâche de développement.

En gros, au lieu de bosser à un seul cerveau, tu bosses à deux.

Deux développeurs en plein pair programming
Deux développeurs en plein pair programming

Photo de Alvaro Reyes sur Unsplash

Cet article est encore en cours de rédaction. Si tu as des suggestions sur ce qui manque, te semble erroné ou si tu te poses encore des questions après avoir lu l’article, tu peux me contacter ici : https://www.linkedin.com/in/benoitgantaume/

Pourquoi travailler en pair programming ?

Quelle drôle d’idée après tout : mettre deux personnes au travail sur une tâche, alors qu’une seule pourrait suffire.

Pourquoi diable y mettre autant d’énergie ?

Si on reste dans une logique productiviste fordienne, cela ne fait aucun sens.
Mais si on prend conscience qu’on est sur une activité complexe, développer un logiciel, qui nécessite des interactions hautement complexes, des humains qui bossent ensemble, on se rend compte que ce n’est pas si stupide.

Deux paires de bras qui travaillent ensemble vont apporter un gain linéaire : 1 + 1 = 2.
Hors, développer demande d’utiliser principalement son cerveau. Et quand deux cerveaux réfléchissent ensemble, le gain n’est plus linéaire.
Parfois 1 + 1 = 11.
Par moments 1 + 1 = 0.

Donc la première raison de travailler en pair programming est que les solutions apportées vont être beaucoup plus riches et le code de bien meilleure qualité.

La deuxième raison est de faire circuler la connaissance.
N’as-tu jamais été stressé à l’idée de partir, toi ou un collègue en vacances ?
Si tu veux pouvoir partir tranquille, il vaut mieux éviter d’être le seul détenteur d’une connaissance. Ça tombe bien, le pair programming est un formidable circulateur de connaissance.

Enfin, d’un point de vue humain, cela permet d’aller à la rencontre de ses collègues d’une manière plus profonde. Mais ce point peut être à double tranchant. On en parle plus bas.

Comment travailler en pair programming ?

Dans le pair programming des origines, les ordinateurs étaient encombrants, onéreux, et les outils de communication peu répandus. Donc on bossait à deux, l’un à côté de l’autre, sur le même ordinateur. Il n’y avait qu’un clavier/souris et une seule personne touchait le clavier pendant que l’autre réfléchissait avec lui.

Aujourd’hui, les ordinateurs portables sont répandus et les outils de communication beaucoup plus développés grâce aux connexions fibrées.

On peut donc élaborer d’autres manières de binômer.

Continuer la lecture de « Pair programming : le guide ultime »