Come praticare TCR (Test e Commit

Articoli sulla home page di InfoQ Come la pratica del TCR (Test e& Commit || Ripristina) riduce le dimensioni del batch

20 febbraio 2023 13 minuti di lettura

di

Filippo Bourgau

recensito da

Matt Campbell

Qualche tempo fa, io e un collega abbiamo eseguito un kata in codice durante una conferenza a Parigi. Ecco i tipi di insegnamenti che le persone hanno espresso alla fine:

Pensavo di fare dei piccoli passi, ma ho scoperto che potevo farli ancora più piccoli!

Ho ancora bisogno di più esperienza con il TDD stesso!

ScyllaDB è il database per app ad uso intensivo di dati che richiedono un throughput elevato e una bassa latenza. Ottieni una scalabilità estrema con il TCO più basso. Saperne di più.

Mi sono perso in un refactoring infinito.

DevOps e Continuous Delivery sono ormai diffusi nel settore. Ma il lavoro viene svolto in piccole porzioni, continuamente integrato e giocato? Molti team lavorano ancora con rami di funzionalità, integrando solo funzionalità complete!

Non sarebbe fantastico se scrivere codice a piccoli passi fosse diventato una seconda natura per gli sviluppatori? Raggiungimento del pieno potenziale dello sviluppo basato su trunk, DevOps e distribuzione continua!

TCR è una tecnica che ti costringe a scrivere codice a piccoli passi! È anche un insegnante severo ma efficace. Impariamo di più a riguardo. Vedremo come gli sviluppatori lo utilizzano per effettuare una consegna più continua e per istruire i propri compagni di squadra:

TCR sta per Test e Commit o Revert. Sostituisce il comando test con un test && commit || ripristinare il comando. Pertanto, gli sviluppatori eseguiranno il comando TCR invece di avviare il test per verificare che il loro codice funzioni. Se il codice funziona come previsto, TCR lo invia al sistema di controllo della versione. Se il codice non funziona, TCR lo ripristina al suo ultimo stato funzionante!

TCR è iniziato come un folle esperimento di Lars Barlindhaug, Oddmund Strømme, Ole Johannessen e Kent Beck durante un Code Camp a Oslo. Kent Beck ha poi sparso la voce attraverso il suo blog. Kent Beck sostiene che dovremmo provare idee stupide perché a volte si rivelano brillanti! Se il TCR sia stupido o brillante è ancora una questione aperta. Eppure le persone che lo seguono abbastanza a lungo lo trovano illuminante!

fonte

Sicuramente imparerai qualcosa. (Kent Beck riguardo al tentativo di TCR)

In effetti, gli sviluppatori che hanno provato seriamente TCR riportano molti vantaggi:

Leggiamo in prima persona cosa dicono. Ecco le interviste con due praticanti del TCR.

Ciao Guillaume, puoi raccontarci di te in poche parole?

Guillaume Faas : Sicuro. Mi chiamo Guillaume e attualmente sono un sostenitore degli sviluppatori .NET presso Vonage. Lavoro nel settore del software da quasi 15 anni, nell'ecosistema .NET fino in fondo. Tuttavia, se dovessi scegliere una pietra miliare della mia carriera, non sarebbe un ruolo o un progetto ma il riconoscimento dell'Arte del Software. In effetti, ha cambiato drasticamente la mia visione dello sviluppo software e c'è un prima e un dopo. Da allora cerco costantemente di diffondere la mentalità e i suoi valori.

Puoi condividere la tua storia nel TCR: come sei arrivato al TCR? Quali sono state le tue prime impressioni?

Faas : La cosa divertente che chiedi. Il mio primo incontro con TCR è stato durante uno dei tuoi workshop, in particolare il gioco del bowling nell'incontro di Software Craftsmanship Luxembourg. Ricordo che il workshop era molto divertente e illuminante. Ma sfortunatamente, i nostri piccoli passi non sono stati così piccoli e abbiamo iniziato a temere di salvare i nostri cambiamenti. Tuttavia ne sono uscito entusiasta e con la voglia di esercitarmi di più.

Oggi per cosa usi il TCR?

Faas: Per essere completamente trasparente, applico il TCR attraverso lo strumento creato dal team di coaching tecnico Murex. Lo utilizzo principalmente per i kata durante le sessioni di coaching. È un ottimo modo per insegnare il TDD perché porta più idee e non è necessariamente più difficile. L'ho usato anche sul codice di produzione, ma consiglierei alle persone di fare attenzione. Verificare che ogni test venga superato ogni volta può rallentare drasticamente il ciclo di feedback. Infine l'ho utilizzato anche durante le prove tecniche come candidato.

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