Bienvenue sur le podcast Artisan Developer,
l'émission dédiée au programmeur qui parle de techniques,
bien sûr, de codes durables, mais aussi du métier en lui-même,
de recrutement, de développement personnel ou encore d'entrepreneuriat
pour t'accompagner dans une vie de développeur épanouissante.
Alors, est-tu prêt à passer au niveau supérieur ?
C'est parti !
Aujourd'hui, je suis avec Jean Pascoalini.
Jean, bonjour.
Bonjour.
Comme c'est la première fois que tu viens sur le podcast,
est-ce que tu peux te présenter en une minute ?
Oui, donc moi, c'est Jean Pascoalini.
Aujourd'hui, je suis lead développeur chez WIND,
certifié en symphonie.

OK.
Ça apporte quoi, la certification ?
Ça apporte que du coup, pas ça certifie en fait que j'ai
analysé toutes les possibilités de l'outil,
que du coup, dans des cas spéciaux,
je sais comment le l'outil se comporte
et quelles sont les solutions qu'ils peuvent utiliser.
OK, cool.
Et aujourd'hui, ce qui m'avait intrigué,
est-ce que je te propose qu'on évoque
et le sujet de cet épisode ?
C'est le TCR, je crois que c'est ça, comme ça, que tu l'appelais ?
Oui, le TCR, absolument.
Est-ce que tu peux nous en dire plus sur ce TCR ?
Alors, le TCR, en fait, c'est une méthodologie, en fait,
de développement qui consiste à,
pendant qu'on fait du TDD, donc le TDD, pour rappel,
c'est le test driving de développement,
c'est à dire qu'on teste pendant qu'on développe,
et pas avant de développer.
Et du coup, on commence à écrire un peu de code,
puis on lance les tests.
Si le test aurait si le code est committé,
on le regarde, si le test échoue,
le code est annulé et revient son état au dernier comité.
Voilà plus ou moins ce que c'est.
Mais c'est à chaque lancement de test ?
À chaque lancement de test.
Donc en gros, tu as ton test qui échoue,
tu as cet emploi en départ,
tu lances, tu essaies d'écrire un bout de code pour faire passer le test.
Si ça passe,
ça commite la petite progression,
sinon ça jette tout, c'est ça ?
Absolument.
Ça paraît un peu radical, dit comme ça.
Tu as essayé toi ?
Oui, j'ai essayé pour le coup.
C'est assez radical, en fait,
quand on n'est pas habitué à travailler dans un mode où
on fait des petits bout de code et après on teste,
parce que du coup, c'est à dire que c'est rompère,
en fait, tout ce qu'on peut écrire.
Et en fait, c'est pas quelque chose
qu'on peut forcer les gens à se mettre sur cette modélologie.
C'est quelque chose où
en l'occurrence, il faut avoir envie de le faire
pour y trouver un intérêt par contre.
Et toi, est-ce que tu as essayé ?
Qu'est-ce que ça t'a apporté ?
J'imagine intuitivement que ça t'amène à faire des étapes super petites,
en fait, pour être sûr d'avoir toujours une batterie verte
et que tu en perdes le moins possible potentiellement.
C'est ça, en fait, ça apporte la méthodologie qui dit
il faut passer une petite partie de son temps dans un petit test,
une petite partie de son temps dans la partie de l'évoquement.
Et là, en fait, du fait que si on passe trop de temps dans un parti d'évoquement,
on risque d'avoir un test qui fait, on risque de perdre plus.
Donc on va avoir tendance à passer un peu moins de temps sur un parti d'évoquement
pour faire des petits évoquements.
Donc on est sûr, en fait, que ça marche et que si ça marche pas au pire,
on part pas grand chose.
Et du coup, comment ça marche ?
T'as une espèce de script ?
C'est quoi, c'est un hook à la fin de ta batterie ?
T'as une espèce de truc comme ça qui fait un guide river ?
En fait, j'ai la chance d'avoir un outil
en qui on se majestutise comme il est de l'HPSP-System.
Et du coup, j'ai un outil qui s'appelle Implaining Wipe Limited
qui apporte cette implementation pour le TCR.
Donc il y a juste à installer,
quand on lance ces tests, automatiquement,
si ça passe, il commite, sinon il reverte.
Il n'y a rien d'autre à faire.
Wow ! Et par contre, du coup, si tu commites,
tu vas empiler plein de micro-commits.
Qu'est-ce que tu fais à la fin ?
Tu consolides ces comites ou tu balances comme ça,
qui t'aura créé un historique monstrueux pour ceux qui vont relire ou parce que
tu pourris un peu ton historique guide ?
Non ?
Oui, absolument.
C'est la partie que j'aime un peu moins sur le métier, c'est la partie comite.
Mais après, on a eu le besoin d'avoir le déploiement de sauillage, justement,
pour pouvoir l'utiliser.
Donc après, il fait juste, en fait,
finalement, de fousonner les comites pour avoir un seul comite au final.
Et ça passe tel quel ?
Niquel.
Est-ce que tu as toi d'autres retours d'expérience sur ça ?
Est-ce que tu as vu des gens chez qui ça ne marchait pas du tout ?
Quels ont été tes galères au début pour mettre ça en œuvre ?
En fait, au début, j'avais essayé à faire comme un peu
comme tout le monde un petit strip pour le faire.
Puis après, je me suis dit, peut-être qu'il y a des choses qui y est.
Donc j'ai cherché des outils.
J'ai fini pas à trouver des outils qui m'ont évité de passer trop de temps
sur essayer de mettre en place ce truc, mais juste l'utiliser.
Et donc j'ai pu commencer à essayer d'utiliser.
Et au final, je fais en du compte que des petits trucs,
tout court, en fait, quand on développe avec cet outil,
c'est que, par exemple, si je commence à écrire
une méthode qui va construire une classe
et qui va la retourner avec des informations qui sont citées à l'intérieur,
par exemple, si je commence à mettre une ligne
qui teste l'instance de la classe pour effet,
que c'est une classe d'une type par exemple, poiture,
je vais juste créer la classe et l'insensier, sachant que si je crée une classe
dans le code, en fait, et qu'elle n'est pas insensée dans mon code,
ça ne va pas faire péter le test, tout ça va être regardé.
Et du coup, à mesure, je vais écrire une assertion
et je vais faire modifier la classe.
Mais au lieu de, par exemple, de faire tout de suite le 7 heures,
ce que j'ai fait dans ma classe, c'est que la propre partie qui est dedans,
par exemple, je mette une valeur par défaut qui vaut celle de mon test.
Comme ça, ça me permet vraiment de faire par petite étape,
ça diminue le risque et c'est plein de petites astuces comme ça
pour réussir à travailler avec, en fait.
Donc on prend cet abus, donc on prend ces petites astuces
qui font qu'on arrive à travailler en petite étape
et pas à faire, par exemple, je fais de la bourse tout mes 7 heures
et ensuite je teste, mais vraiment, petit par petit.
Du coup, je me demande, est-ce qu'il n'y a pas un risque aussi
pour que tu sois tenté de faire que du vert
et du coup, plus être en test first,
plus écrire le test d'abord et être tenté de l'écrire après, tu crois.
Parce que du coup, dès que tu as un test rouge,
ça veut dire que ça passe pas, enfin, même,
comment tu fais pour écrire un test rouge, puisque par définition,
quand tu vas écrire un test qui échoue,
ça va faire échouer la batterie, donc il va se faire rollbacker le test.
Oui.
C'est une matogé particulière, donc du coup, c'est pas...
Mais est-ce que ça veut dire que, du coup, tu ne vois plus ta batterie rouge, en fait ?
Non, tu ne vois plus ta batterie rouge, mais si tu la vois rouge en confiance,
tu vas être verte.
Oui, c'est vraiment pas bon.
Mon final, disons que ça force juste à écrire des petits bout de code, en fait.
C'est un peu différent, c'est-à-dire que, effectivement,
le but, c'est pas de l'avoir écrivé un test qui fait,
il y a après à écrire le code, mais plus d'écrire des bout de code
qui soient le plus simples possible.
Bah, c'est du coup, comme on a besoin d'écrire un pot de code,
on va chercher à les simplifier pour le code,
soit pas complexe, on écrivra des choses un peu farfelues
ou fait frapper avec cette zèle.
Et également, à faire des choses qui passent,
ça rapidement, donc c'est un désir davantage,
justement, c'est que c'est une force à faire simple et court.
Et toi, alors, est-ce que tu l'as gardé dans ton process
ou c'était juste une expérience, et maintenant,
tu l'as mis de côté ou tu l'as gardé dans ton manière de travailler au quotidien ?
Alors, en fait, je ne vois pas ça comme une obligation,
donc en fait, je ne pense pas que je l'utiliserai forcément tous les jours,
mais je trouve que c'est très intéressant parce que je trouve que pour moi,
ça me fait un challenge, on va dire en vrai,
de me dire, il faut que je fasse attention à ce que je fais,
parce que si je fais des choses qui ne marchent pas,
je ne les avoirai pas d'avoir,
donc du coup, ça ne me permet de être plus consensieux dans ce que je fais,
et pas juste de me dire, c'est pas grave, si ça ne passe pas beaucoup.
Donc, c'est un challenge supplémentaire,
je pense pas que c'est obligatoire,
au final, je pense que ça sert à surtout de l'envie d'avoir ce challenge supplémentaire
quand j'écris mon code,
parce que j'ai déjà la méthode d'envie de voir des choses assez simples,
je pense, en soi,
mais c'est sûr que ça la renforce parce que les moments où on est un peu fatigué
ou on n'a pas envie de s'embêter, on est quand même obligés de le faire.
Ok.
Bah écoute, merci pour ce retour d'expérience,
c'était super intéressant.
Si les auditeurs veulent en savoir un petit peu plus sur ce que tu cries
ou le code que tu cries ou si tu cries des articles,
ils peuvent venir où ?
Alors pour le coup, j'ai un guitube qui s'appelle Jean-François Rouigny,
et ensuite, j'ai mon incudine,
je n'ai pas spécialement de blog,
à part le dernier article que j'ai écrit sur Artisan de Wepar.
Ok.
Béle article d'ailleurs sur la métaphore du cuisinier qui va en province
pour développer son art aussi, c'était super intéressant d'ailleurs.
Merci encore Jean pour ce article.
Quant à toi, chers auditeurs, j'espère que t'as apprécié ce podcast.
Je t'invite à nous rejoindre sur Artisan Developer,
tu y trouveras tous les épisodes du podcast,
mais aussi les articles, et notamment celui que Jean a mentionné.
Et je te dis à demain.