Cómo practicar TCR (prueba y compromiso)

Artículos de la página de inicio de InfoQ Cómo la práctica de TCR (prueba y confirmación || revertir) reduce el tamaño del lote

20 de febrero de 2023 Lectura de 13 minutos

por

Philippe Bourgau

revisado por

matt campbell

Hace un tiempo, un colega y yo ejecutamos un código kata en una conferencia en París. Estos fueron los tipos de aprendizajes que la gente expresó al final:

Pensé que estaba dando pequeños pasos, ¡pero descubrí que podía hacerlos aún más pequeños!

¡Todavía necesito más experiencia con el TDD!

ScyllaDB es la base de datos para aplicaciones con uso intensivo de datos que requieren alto rendimiento y baja latencia. Logre una escala extrema con el TCO más bajo. Aprende más.

Me perdí en una refactorización interminable.

A estas alturas, DevOps y la entrega continua están muy extendidos en la industria. Pero, ¿el trabajo se realiza en pequeñas porciones, se integra continuamente y se juega con él? ¡Muchos equipos todavía trabajan con ramas de funciones, integrando solo funciones completas!

¿No sería fantástico si escribir código en pequeños pasos se hubiera convertido en algo natural para los desarrolladores? ¡Logrando todo el potencial del desarrollo basado en troncales, DevOps y entrega continua!

¡TCR es una técnica que te obliga a escribir código en pequeños pasos! También es un maestro duro pero eficaz. Aprendamos más al respecto. Veremos cómo los desarrolladores lo utilizan para realizar una entrega más continua y entrenar a sus compañeros de equipo:

TCR significa Prueba y confirmación o reversión. Reemplaza el comando de prueba con una prueba && commit || revertir comando. Por lo tanto, los desarrolladores ejecutarán el comando TCR en lugar de iniciar la prueba para verificar que su código esté funcionando. Si el código funciona como se esperaba, TCR lo envía al sistema de control de versiones. Si el código no funciona, TCR lo revierte a su último estado de funcionamiento.

TCR comenzó como un experimento loco realizado por Lars Barlindhaug, Oddmund Strømme, Ole Johannessen y Kent Beck durante un Code Camp en Oslo. Kent Beck luego hizo correr la voz a través de su blog. Kent Beck afirma que deberíamos probar ideas estúpidas porque, a veces, ¡resultan brillantes! Si TCR es estúpido o brillante sigue siendo una cuestión abierta. Sin embargo, las personas que lo siguen durante el tiempo suficiente lo encuentran esclarecedor.

fuente

Seguro que aprenderás algo. (Kent Beck sobre probar TCR)

De hecho, los desarrolladores que probaron seriamente TCR informan de muchos beneficios:

Leamos lo que dicen de primera mano. Aquí hay entrevistas con dos practicantes de TCR.

Hola Guillaume, ¿puedes hablarnos de ti en pocas palabras?

Guillaume Faas : Seguro. Mi nombre es Guillaume y actualmente soy promotor de desarrolladores .NET en Vonage. Llevo casi 15 años en la industria del software, en el ecosistema .NET de principio a fin. Sin embargo, si tuviera que elegir un hito de mi carrera, no sería un puesto o un proyecto, sino el reconocimiento de Software Craftsmanship. De hecho, cambió drásticamente mi visión sobre el desarrollo de software, y hay un antes y un después. Desde entonces, intento constantemente difundir esta mentalidad y sus valores.

¿Puedes compartir tu historia de TCR: cómo llegaste a TCR? ¿Cuáles fueron tus primeras impresiones?

faas : Es curioso que preguntes. Mi primer encuentro con TCR fue durante uno de sus talleres, específicamente, el juego de bolos en la reunión de Software Craftsmanship Luxemburgo. Recuerdo que el taller fue muy divertido y esclarecedor. Pero desafortunadamente, nuestros pequeños pasos no fueron tan pequeños y comenzamos a tener miedo de guardar nuestros cambios. Sin embargo, salí entusiasmado con la voluntad de practicar más.

Hoy en día, ¿para qué utilizas el TCR?

Faas: Para ser totalmente transparente, aplico TCR a través de la herramienta que creó el equipo de coaching tecnológico de Murex. Lo uso principalmente para katas durante las sesiones de entrenamiento. Es una excelente manera de enseñar TDD porque aporta más ideas y no es necesariamente más difícil. También lo usé en código de producción, pero recomendaría a la gente que tuviera cuidado. Verificar que todas las pruebas pasen cada vez puede ralentizar drásticamente el ciclo de retroalimentación. Finalmente, también lo usé durante las pruebas técnicas como candidato.

¿Qué beneficios ha notado al utilizar TCR en el contexto de capacitación?

Faas: La gente se da cuenta de que no confía en el código que escribe. Como dije antes, temíamos guardar nuestros cambios. Existe una conexión clara con la siguiente cita de Kent Beck: "El desarrollo basado en pruebas es una forma de gestionar el miedo durante la programación". Además, todos pensamos que trabajamos en pequeños incrementos. Spoiler: todos estamos equivocados. TCR te obliga a ir poco a poco y con frecuencia, lo que aporta muchos beneficios, incluido un ritmo sostenible y un trabajo menos agotador.

¿Cómo suele reaccionar la gente cuando se enfrenta al TCR durante el entrenamiento?

Faas: "Oh no, voy a perder mi código". Y puede que tenga razón. Pero la gente rápidamente se da cuenta de que sólo perderán un poco si reducen sus ciclos de TDD. También se vuelve bastante adictivo y divertido. Le recomendamos que desafíe su confianza en el código que acaba de escribir. He observado lo siguiente cada vez: la gente comenzó a apostar en el resultado de la prueba antes de ejecutar las pruebas.

¿A qué desafíos se enfrentó o sigue enfrentando al utilizar TCR para la capacitación?

Faas: La gente suele sentirse intimidada. Creen que necesitan aprender otra cosa simultáneamente, lo cual está mal. Además, revertir el código parece una pérdida de productividad. Así que el desafío es hacer que lo intenten de todos modos.

¿Tiene alguna recomendación para los lectores que quieran utilizar TCR para practicar o capacitar a otros?

Faas: La publicación del blog de Kent Beck sobre el tema en sí es una excelente manera de comenzar. Además, siendo un lector constante, sólo puedo recomendar tu blog. Contiene artículos fantásticos como, por ejemplo, el de diseño evolutivo. De lo contrario, la práctica hace la perfección. Así que únete a algunas personas para kata y experimenta. Es divertido y seguro que aprenderás algo.

¿Dónde ve TCR en el futuro de la ingeniería de software?

Faas: Esa es una dificil. Defiendo TDD y TCR tanto como puedo. Aunque TCR es bastante reciente (2018, si mal no recuerdo), TDD se remonta a principios de los 90 y aún necesita una adopción generalizada. La mayoría de los desarrolladores con los que me encuentro nunca escribieron una prueba o, peor aún, ¡son alérgicos a las pruebas! Es posible que tengamos que pasar varios años antes de que TCR se convierta en algo real. Como profesionales, debemos correr la voz y acelerar su adopción.

Según usted, ¿qué deberíamos hacer para acercar a TCR un paso más a esa visión?

Faas: Tengo que volver a la pregunta anterior. Todos sabemos que TDD es una práctica hermosa y la mayoría de los líderes intelectuales están de acuerdo. ¿Pero dónde falló? ¿Cómo no se adopta más, dada la cantidad de charlas, libros y artículos que alaban sus beneficios? ¿Cómo garantizamos un resultado diferente? No tengo una solución mágica. Debemos generar conciencia sobre el tema, una turba a la vez.

Hola Xavier, ¿puedes hablarnos de ti en pocas palabras?

Xavier Detant : Actualmente soy CTO en Great Place To Work France y pronto me uniré a Eove. Trabajé durante diez años como contratista antes de trabajar a tiempo completo en una empresa de software. Descubrí TDD y lo adopté hace 8 o 9 años. Soy padre de un niño muy lindo y esposo de una esposa encantadora.

¿Puedes compartir tu historia de TCR: cómo llegaste a TCR? ¿Cuáles fueron tus primeras impresiones?

Relajación : Descubrí TCR, como muchos, a través de la publicación del blog de Kent Beck. Mi primer pensamiento fue: “eso suena como una restricción interesante para un kata”, así que lo probé. Al principio, me recordó la restricción "tu computadora tiene un defecto", donde un script en segundo plano restablece tu código a través de git cada dos minutos, y solo puedes confirmar cuando está en verde. La principal diferencia es que el script es tu prueba y el ciclo es tan largo o corto como quieras. Mi primera reacción fue: "Me encanta para refactorizar, pero no ver ninguna prueba en rojo es muy incómodo". Tenía curiosidad por saber si la incomodidad persistiría, así que hice más katas. Al hacerlo, realmente lo disfruté:

Realmente no me gustó lo siguiente:

Por eso, adapté el flujo de TCR para acercarlo más a TDD, pero me quedé con las cosas que me gustaban de TCR. La simétrica de TCR es TRC: ejecutar las pruebas; si es verde, revertir; de lo contrario, comprométete. Eso encaja muy bien con la fase roja de TDD. Entonces creé un script para hacer eso (y simplificar algunas complejidades como evitar confirmaciones rojas cuando presionas). Me gustó el resultado y lo he estado usando desde entonces.

¿Para qué se utiliza el TCR?

Relajación : Lo uso para todo lo que codifico. Completa mi flujo de trabajo TDD.

¿Qué beneficios ha notado al utilizar TCR en su trabajo diario?

Relajación : Un beneficio individual es la retroalimentación sobre su estado de fatiga. Si estás demasiado cansado para hacer un buen movimiento, literalmente te quedas atascado. Y ves que el tamaño de tus pasos se reduce durante el día. Así que eres consciente de ello en cualquier momento y al mismo tiempo vas tan rápido como puedas.

¿Cuáles son los impactos del uso de TCR en el proceso de construcción del software?

Relajación : Un beneficio organizacional es la mejora de la integración y entrega continua. En cualquier momento, cualquier persona con acceso a la plataforma de preproducción puede ver lo que he hecho en mi tarea y dar su opinión. Dio un gran paso adelante en agilidad, ya que podemos redactar algo, empezar a usarlo al mismo tiempo y mejorar según la primera impresión. Eso también significa que no hay resentimientos:

Eso es súper cómodo, relajado y constructivo.

¿A qué desafíos se enfrentó o sigue enfrentando al utilizar TCR en el trabajo de producción?

Relajación : El principal desafío es no “hacer trampa”. En su IDE, está a solo CTRL+Z de recuperar el código que acaba de perder (Nota: justo después de que se revirtiera TCR). Si lo perdiste, hay una razón. ¡Detente y piensa en ello! Por supuesto, el pragmatismo es clave. Si vio un error tipográfico al mismo tiempo que realizaba las pruebas, permítase hacer trampa. Sí, todavía lo enfrento, especialmente al final del día, cuando no quiero admitir que estoy demasiado cansado para hacer un trabajo de calidad y quiero terminar lo que estoy haciendo. Cada vez que hacía trampa por ese motivo, me arrepentía al día siguiente.

¿Tiene alguna recomendación para los lectores que quieran empezar a utilizar TCR?

Relajación : Pruebe TCR solo para la fase de refactorización al principio. Luego, descubre con katas y comienza a usarlo en el código de producción. Finalmente, si te gusta, encuentra una manera de expandirlo fuera de los pasos de refactorización.

¿Dónde ve TCR en el futuro de la ingeniería de software?

Relajación : No creo que TCR llegue tan lejos como lo hizo TDD (y TDD todavía no es omnipresente). Sin embargo, creo que será un muy buen punto de partida para nuevas ideas de trabajo. Lamentablemente, en lo que respecta a TDD, probablemente tendremos que esperar 20 años para ver cómo diferentes formas de trabajar se vuelven “convencionales”.

Según usted, ¿qué deberíamos hacer para acercar a TCR un paso más a esa visión?

Relajación : Pruebe ideas. No mejoraremos nuestra forma de trabajar si no intentamos cosas, incluso las “obviamente estúpidas”. Tenemos el lujo de poder crear proyectos paralelos por diversión. Se nos permite fracasar en nuestros proyectos paralelos por razones tontas. Aprovechemos eso. Diablos, la mayoría de los proyectos pueden darse el lujo de fracasar por razones tontas, ya que muchos proyectos todavía fracasan por razones "no tontas" como:

Si un producto no es crítico para la vida, una opción es utilizar formas de trabajo nuevas y no probadas. ¡Toma riesgos! Nuestro campo es nuevo y tenemos mucho que descubrir, probar y aprender. ¡Sé un explorador y comparte tus aventuras con nosotros!

Mis colegas y yo también hemos estado practicando TCR y ¡observamos más beneficios!

TDD, seguido del libro, da como resultado una alta cobertura por diseño. ¡Al aplicar una TDD estricta, la TCR produce una cobertura aún mayor! TCR conduce a una cobertura sólida de sucursales del 90% o más. El código restante descubierto son constantes o código adhesivo.

Una mayor cobertura es otra forma en que TCR mejora la integración continua y el flujo de entrega. Al detectar errores desde el principio, las pruebas de los desarrolladores evitan fallos en el proceso descendente.

La transferencia de Git es una forma sencilla, sólida, eficaz y económica de realizar un emparejamiento remoto. Funciona por:

Al realizar continuamente pequeños cambios de código, TCR hace que git-handover sea fluido. Es fácil modificar el script TCR para activarlo cuando se confirma. También podemos automatizar la incorporación de los últimos cambios. ¡Cambiar de roles en la mafia se vuelve tan simple como comenzar a compartir pantalla!

TDD es difícil de enseñar porque aplicarlo en código de producción "peludo" es complicado para los principiantes. Sorprendentemente, ¡es más fácil para la gente comprar en TCR! TCR parece una locura y la gente ni siquiera piensa en utilizarlo en su trabajo diario. Como formadores, les explicamos que es una herramienta para ayudarles a practicar la programación paso a paso. Adoptan una mentalidad de "entrenamiento" constructiva. Más tarde, de vuelta en sus escritorios, pueden dividir su trabajo en pasos más pequeños, ¡incluso en bases de código heredadas y no probadas!

Guillaume y Xavier dijeron que la mejor manera de empezar con TCR es probarlo en un kata. Simplemente ejecuta git init y usa un comando diferente para tus pruebas:

&& git commit -am "TCR" || git restaurar.

Si desea un poco más de detalles, existen muchas herramientas de código abierto para TCR:

¡Acostúmbrate al TCR en algunos katas! Luego, una vez que lo domines, si tienes pruebas lo suficientemente rápidas en tu código de producción, ¡pruébalo con refactorización pura!

Escribir para InfoQ ha abierto muchas puertas y aumentado las oportunidades profesionales. para mí. Pude interactuar profundamente con expertos y líderes de opinión para aprender más sobre los temas que cubrí. Y también puedo difundir mis conocimientos a la comunidad tecnológica en general y comprender cómo se utilizan las tecnologías en el mundo real.

¡Descubrí el programa de colaboradores de InfoQ a principios de este año y lo he disfrutado desde entonces! Además de brindarme una plataforma para compartir aprendizaje con una comunidad global de desarrolladores de software, el sistema de revisión entre pares de InfoQ ha mejorado significativamente mi escritura. . Si está buscando un lugar para compartir su experiencia en software, comience a contribuir a InfoQ.

Comencé a escribir noticias para la cola InfoQ .NET como una forma de mantenerme actualizado con la tecnología, pero saqué mucho más provecho de ello. Conocí gente conocedora, obtuve visibilidad global y mejoré mis habilidades de escritura..

Convertirme en editor de InfoQ fue una de las mejores decisiones de mi carrera . Me ha desafiado y me ha ayudado a crecer de muchas maneras. . Nos encantaría tener más gente.Unete a nuestro equipo.

InfoQ busca un editor en jefe a tiempo completo para unirse al equipo internacional y siempre remoto de C4Media. Únase a nosotros para cubrir las tecnologías más innovadoras de nuestro tiempo, colabore con los profesionales de software más brillantes del mundo y ayude a más de 1,6 millones de equipos de desarrollo a adoptar nuevas tecnologías y prácticas que superan los límites de lo que el software y los equipos pueden ofrecer.

Todos los martes se envía un resumen del contenido de la semana pasada en InfoQ. Únase a una comunidad de más de 250.000 desarrolladores senior. Ver un ejemplo

Protegemos su privacidad.

Debe registrar una cuenta InfoQ o iniciar sesión o iniciar sesión para publicar comentarios. Pero hay mucho más detrás de estar registrado.

Aproveche al máximo la experiencia InfoQ.

HTML permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML permitido: a,b,br,blockquote,i,li,pre,u,ul,p