XP, TDD et vibe coding : traduction partielle de l’interview de Kent Beck par Programmatic Engineer

• Résumé de quelques passages qui m’ont particulièrement marqué dans l’interview de Programnatic Engineer avec Kent Beck, le père de XP et de TDD
• Si vous aimez Kent Beck, je vous recommande de regarder la version complète

---

Q. Quel est le cœur de XP ?

Il s’agit de pratiquer les quatre activités suivantes.

1. Comprendre ce qu’il faut faire
2. Comprendre quelle structure nous permet de faire 1
3. Utiliser 2 pour implémenter 1
4. Vérifier que 3 fonctionne comme prévu

C’est tout. Ensuite, on découpe le temps très finement : à chaque instant, on fait un peu des quatre activités, mais on les fait toutes.

Q. Donc le pair programming n’est pas indispensable dans XP ?

À l’époque où je dirigeais ma première équipe XP, on livrait toutes les trois semaines, et il y avait naturellement des bugs.

J’ai analysé les schémas des bugs découverts après le déploiement, et ils provenaient tous de code développé seul. Dit autrement, le code développé en pair n’avait donné lieu à aucun défaut signalé en production.

Q. Donc ce n’est pas obligatoire, mais c’est fortement recommandé ?

Même pas. Ce qu’il faut, c’est expérimenter. Vous pouvez continuer à développer comme d’habitude. Mais en restant pleinement attentif.

Vous voulez tirer un bénéfice du design continu, de la validation continue, de l’implémentation continue, ou encore de l’interaction continue avec le client ? Mais en procédant toujours comme avant, ça ne marche pas ? Alors il faut changer de méthode.

Si quelqu’un vient me voir et me dit : « Kent, moi je ne fais pas de TDD. » Je réponds : « Et alors ? »

Si vous êtes satisfait de la densité de défauts de votre code actuel et du niveau de feedback sur vos décisions de conception, aucun problème. Mais si ce n’est pas le cas, alors essayez le pair programming ou le TDD.

Q. Puisqu’on en parle, pourquoi avoir créé le TDD ?

Je suis quelqu’un qui s’inquiète beaucoup, et la programmation a longtemps été pour moi une source permanente d’anxiété. Qu’est-ce que j’ai oublié ? Qu’est-ce que j’ai cassé ?

Mais quand je développe en TDD, cette anxiété disparaît. Vous n’arrivez plus à imaginer de cas de test susceptibles d’échouer ? Alors vous pouvez avoir confiance dans le fait que votre programme fonctionne. Un peu d’anxiété réapparaît ? Il suffit d’écrire le cas de test suivant.

Bien sûr, le TDD apporte aussi de nombreux bénéfices techniques : réduire la densité de défauts, obtenir plus vite du feedback sur les décisions de conception, faire évoluer la conception de l’implémentation, etc. Mais pour moi, le plus important, c’est d’avoir été libéré de l’anxiété liée à la programmation, et que l’expérience émotionnelle même de programmer ait complètement changé. C’est pour cela que j’ai créé le TDD.

Q. Que pensez-vous de la critique de John Ousterhout, selon laquelle le TDD ne laisse pas de place à une bonne conception ?

(Note du traducteur : John Ousterhout est l’auteur de l’ouvrage de référence Philisophy of Software Design, et il est aussi passé il y a quelques mois dans le podcast Programmatic Engineer, où il a exposé une vision critique du TDD)

Il y a chez lui une part de malentendu. Ce n’est au fond qu’un résultat de prise de décision. Si on réduit le TDD à une simple répétition Red-Green, alors évidemment il n’y a plus d’espace pour la conception.

En tant que praticien du TDD, je navigue en permanence entre différents niveaux d’abstraction. Par exemple :

• Là, je suis en état Red. Comment implémenter ce qu’il faut pour faire passer le prochain test au vert (Green) ?
• Tiens, c’est difficile. Pourquoi est-ce difficile ?
• Comment faire évoluer la conception pour rendre plus simple l’implémentation nécessaire au passage en Green ?
• Quand faut-il introduire cette idée ? Maintenant, ou plus tard ?
• Si je l’introduis maintenant, jusqu’où aller ? Faire juste un petit pas possible immédiatement, ou avancer par un bloc plus large ?

Autrement dit, avant même d’écrire un test, j’ai toujours un moment de conception.

Avant d’implémenter, je prends des décisions sur l’interface, je crée un test Red, puis, comme je n’aime pas être en Red, je passe en Green aussi vite que possible. Une fois en Green, l’anxiété s’apaise un instant, ce qui laisse de la place pour réfléchir. « Hum, ça passe, mais ça ne marchera pas pour d’autres cas. Il faut généraliser davantage l’implémentation. »

Je suis en Red ? Je passe en Green. Je suis en Green ? Je souffle un peu et je réfléchis. Voilà mon cycle TDD.

Q. Il m’arrive parfois de trouver l’implémentation tellement évidente que je code d’abord, puis je fais les tests Red-Green ensuite. Que pensez-vous de cette façon de faire ?

C’est sans doute parce que vous partez de l’hypothèse que « cette manière d’implémenter est la bonne », et plus cette hypothèse est correcte, plus l’intérêt d’écrire les tests en premier diminue naturellement.

Mais moi, je pars toujours de l’idée suivante : « Je vais continuer à apprendre et à accumuler de l’expérience, et en ce moment précis je suis à mon niveau maximal d’ignorance. »

Autrement dit, je pars du principe que je vais continuer à apprendre, et que la situation va changer. Plus j’ai besoin d’apprendre, et plus les choses sont susceptibles d’évoluer, plus j’ai envie de repousser les décisions au maximum. C’est un principe général. Que l’on parle de rencontres amoureuses ou de cuisine, c’est pareil.

Plus on peut prédire, plus on peut faire de grands sauts. Mais le moment que j’aime le plus en programmation, c’est quand je pense tout savoir, que j’avance à fond, puis que je me rends soudain compte qu’il existait une bien meilleure manière d’implémenter. Je veux vivre ce moment aussi souvent que possible. C’est pour cela que je fais du TDD.

Si vous avez une image très nette en tête et la certitude de ce que telle entrée produira comme sortie, alors allez-y et implémentez directement. Mais plus vous faites d’erreurs, plus vous apprenez, plus le monde devient imprévisible, plus il est avantageux de ne pas vous engager tout de suite et de remettre la décision à plus tard.

Q. Avec l’IA, continuez-vous à développer en TDD comme avant ?

Il est difficile de répondre simplement.

J’utilise surtout les tests comme moyen de communication avec l’IA, principalement pour lui indiquer ce qu’elle a mal fait. Cette petite chose essaie sans arrêt de supprimer ou de modifier mes tests, et à chaque fois je la remets à sa place : mes tests sont corrects, donc fais ton travail correctement.

L’IA prend souvent de mauvaises décisions à long terme. Elle est aussi très mauvaise pour réduire le couplage et augmenter la cohésion. Si on lui dit extrêmement clairement quoi faire, elle peut y arriver, mais en général il faut considérer qu’elle ne conçoit pas bien.

C’est pourquoi je prépare énormément de tests. Je m’en sers comme d’un moyen de détecter si l’IA est en train de tout casser.

(Note du traducteur : pour voir comment Kent Beck applique le TDD au vibe coding, voir cet article)

Q. Si des règles d’agent du type « ne jamais corriger les tests » ou « si les tests ne passent pas, ne modifie que le code d’implémentation jusqu’à ce qu’ils passent » se généralisent, cela rendra peut-être les choses plus simples. On a aussi l’impression que l’époque actuelle redécouvre des choses importantes dans les années 2000. Qu’en pensez-vous ?

Il faut continuer à expérimenter. Il faut tout essayer. Parce qu’en ce moment, on ne sait pas vraiment ce qui est le mieux.

Notre horizon de ce qui est « bon marché » et de ce qui est « coûteux » a complètement changé. Beaucoup de choses qu’on ne faisait pas autrefois parce qu’elles étaient considérées comme chères ou difficiles sont devenues ridiculement peu coûteuses.

Si, du jour au lendemain, les voitures devenaient gratuites, qu’est-ce qui se passerait à votre avis ? Bien sûr, quelque chose changerait. Mais quels seraient les effets secondaires et tertiaires ? Personne ne peut le prévoir. Donc pour l’instant, on n’a pas d’autre choix que d’essayer beaucoup de choses.

Q. Vous avez dit qu’après plus de 50 ans de programmation, vous vous amusez aujourd’hui plus que jamais. Qu’entendez-vous par là ?

Il n’a jamais été aussi facile de concrétiser mes grandes idées. Observer l’IA tenter de mettre en œuvre une idée, puis l’ajuster pour voir comment elle va s’y prendre, est extrêmement addictif. On ne sait jamais vraiment quand cela va marcher, et quand cela marche presque magiquement, c’est euphorisant — un peu comme une machine à sous. Avant d’aller me promener ou déjeuner, je suis toujours tenté de lui laisser au moins un prompt pour qu’elle continue à jouer pendant mon absence.

Il y a deux ans, j’avais publié ce tweet : « J’étais réticent à utiliser ChatGPT, et aujourd’hui j’ai compris pourquoi. 90 % de mes compétences valent désormais $0. Et les 10 % restants ont vu leur effet de levier multiplié par 1000. Il est temps de recalibrer mes compétences. »

> I've been reluctant to try ChatGPT. Today I got over that reluctance. Now I understand why I was reluctant.
>
> The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate.
>
> -- Kent Beck 🌻 (@KentBeck) April 18, 2023

(Note du traducteur : quand ce tweet a fait parler de lui, Kent a ensuite publié un texte un peu plus long.)

À l’époque, il disait qu’il explorait encore ce que représentaient ces 90 % et ces 10 %, mais aujourd’hui il peut répondre en partie. Avoir une vision ambitieuse, savoir fixer des jalons vers cette vision, ajuster en continu la conception tout en avançant, et maîtriser la complexité. Ce sont des compétences biiiien plus importantes que la connaissance de la syntaxe d’un langage particulier (par exemple : où placer &, *, [ en Rust).