Conoce este flujo de trabajo, gracias a una charla que dieron en mi actual empresa, esta charla se basaba en un post que nos dejo Kent Beck en septiembre de 2018 (medium).
Al escuchar la charla, me hice una idea general de que era TCR y como aplicarlo. Realmente la primera impresión era que es un flujo de trabajo de DDD «radicalizado», obliga a hacer pequeños cambios, lanzar los test y en el caso de que fallen replantear el cambio
Tabla de contenidos
TCR (test && commit || revert)
El workflow es bastante sencillo y a la vez agresivo. La primera parte del ciclo, es igual que en DDD, con algunos detalles:
- Generar el test
- Commit del test
- Generar el código de negocio
- Guardar
- Lanzar los test
Y aquí viene el pilar del TCR, en el caso de que el punto 5 (test) falle, se lanza «git reset –hard HEAD«, volviendo al código «original» obligando a que nos replanteemos el código que hicimos previamente.
Como, cuando y porque
Como siempre, este enfoque no es apropiado para todo el mundo y creo que tiene una finalidad bastante clara. Poner limites en nuestro desarrollo en DDD, aplicando este enfoque nos limitaremos ha hacer pequeños cambios increméntales que no rompan la lógica de negocio.
Una vez interioricemos el DDD como un enfoque incremental, podríamos obviar el TCR, pero si has entrado en DDD, estas cómodo y quieres mejorar tu proceso de desarrollo un enfoque como este, te ayudara a refinar este aspecto del desarrollo.
Caso de uso con GO + VIM
Al usar vim, me ha permitido añadir un pequeño tigger:
autocmd BufWritePost *.go !go test . | awk -F@ '/FAIL/ {system("git reset --hard HEAD")}'Al poner esta linea en nuestra configuración de vim, haremos que cada vez que exista una modificación de un fichero .go, se lance los comandos que nos permiten hacer rollback de nuestro código en el caso de que falle.
Disclaimer: Tener en cuenta que este es un caso muy sencillo, pero debería poder ser usado en cualquier caso con algunas consideraciones
Este seria el estado inicial de nuestro proyecto, con los test ya creados y en «verde».
Hacemos una modificación, para que la suma devuelva 0, con lo cual los test fallaran
El set de test ha fallado, por lo tanto, al continuar
Realmente es un enfoque muy radical, pero a tener en cuenta si queremos mejorar la cantidad de código que escribimos en cada iteración y cuanto nos queremos arriesgar