Comment pratiquer le TCR (Test && Commit

Accueil InfoQ Articles Comment la pratique du TCR (Test && Commit || Revert) réduit la taille des lots

20 février 2023 13 min de lecture

par

Philippe Bourgau

revu par

Matt Campbell

Il y a quelque temps, un collègue et moi avons exécuté un code kata lors d'une conférence à Paris. Voici les types d’apprentissages que les gens ont exprimés à la fin :

Je pensais faire de petits pas, mais j'ai découvert que je pouvais les rendre encore plus petits !

J'ai encore besoin de plus d'expérience avec le TDD lui-même !

ScyllaDB est la base de données pour les applications gourmandes en données nécessitant un débit élevé et une faible latence. Atteignez une évolutivité extrême avec le TCO le plus bas. Apprendre encore plus.

Je me suis perdu dans une refactorisation sans fin.

Le DevOps et la livraison continue sont désormais largement répandus dans le secteur. Mais le travail est-il effectué en petites tranches, continuellement intégré et joué avec ? De nombreuses équipes travaillent encore avec des branches de fonctionnalités, intégrant uniquement des fonctionnalités complètes !

Ne serait-il pas formidable si l'écriture de code par petites étapes était devenue une seconde nature pour les développeurs ? Réaliser tout le potentiel du développement basé sur Trunk, du DevOps et de la livraison continue !

TCR est une technique qui vous oblige à écrire du code par petites étapes ! C'est aussi un professeur dur mais efficace. Apprenons-en davantage. Nous verrons comment les développeurs l'utilisent pour effectuer une livraison plus continue et pour coacher leurs coéquipiers :

TCR signifie Test and Commit ou Revert. Il remplace la commande test par un test && commit || commande de retour. Ainsi, les développeurs exécuteront la commande TCR au lieu de lancer un test pour vérifier que leur code fonctionne. Si le code fonctionne comme prévu, TCR le valide dans le système de contrôle de version. Si le code ne fonctionne pas, TCR le rétablit à son dernier état de fonctionnement !

TCR a commencé comme une expérience folle menée par Lars Barlindhaug, Oddmund Strømme, Ole Johannessen et Kent Beck lors d'un Code Camp à Oslo. Kent Beck a ensuite fait passer le message via son blog. Kent Beck prétend que nous devrions essayer des idées stupides parce que parfois, elles s'avèrent géniales ! La question de savoir si le TCR est stupide ou brillant reste ouverte. Pourtant, ceux qui s’y tiennent assez longtemps le trouvent éclairant !

source

Vous apprendrez forcément quelque chose. (Kent Beck à propos d'essayer le TCR)

En effet, les développeurs qui ont sérieusement essayé le TCR font état de nombreux avantages :

Lisons ce qu'ils disent de première main. Voici des entretiens avec deux praticiens du TCR.

Bonjour Guillaume, peux-tu nous parler de toi en quelques mots ?

Guillaume Faas : Bien sûr. Je m'appelle Guillaume et je suis actuellement développeur .NET chez Vonage. Je travaille dans l'industrie du logiciel depuis près de 15 ans, dans l'écosystème .NET jusqu'au bout. Cependant, si je devais choisir un jalon de ma carrière, ce ne serait pas un rôle ou un projet mais la reconnaissance du Software Craftsmanship. En effet, cela a radicalement changé ma vision du développement logiciel, et il y a un avant et un après. Depuis, j’essaie constamment de diffuser cet état d’esprit et ses valeurs.

Pouvez-vous partager votre histoire TCR : comment êtes-vous entré dans le TCR ? Quelles ont été vos premières impressions ?

Faas : C'est drôle que vous demandiez. Ma première rencontre avec TCR a eu lieu lors d'un de vos ateliers, plus précisément, le jeu Bowling dans le cadre du meetup Software Craftsmanship Luxembourg. Je me souviens que l'atelier était tellement amusant et instructif. Mais malheureusement, nos petits pas n’étaient pas si petits et nous avons commencé à craindre de sauvegarder nos modifications. Néanmoins, j’en suis ressorti excité avec la volonté de pratiquer davantage.

Aujourd’hui, à quoi sert-on le TCR ?

Faas : Pour être totalement transparent, j'applique le TCR via l'outil créé par l'équipe de coaching technique Murex. Je l'utilise principalement pour les katas lors des séances de coaching. C'est une excellente façon d'enseigner le TDD car cela apporte plus d'idées et n'est pas nécessairement plus difficile. Je l'ai également utilisé sur du code de production, mais je conseille aux gens d'être prudents. Vérifier que chaque test réussit à chaque fois peut ralentir considérablement votre boucle de rétroaction. Enfin, je l'ai également utilisé lors d'examens techniques en tant que candidat.

&& git commit -am "TCR" || git restore. /p>