lunes, 18 de enero de 2021

eXtreme Programming: ¿TDD y Cobol ? (agilecobol)

Hace un par de meses fui a un meetup del grupo "Madriagil - Grupo Meetup de Agilismo de Madrid", organizado por Javier de NeuronUp, sobre eXtreme Programming (XP).

Si no estáis en el grupo, os lo recomiendo. Salen siempre meetups interesantes organizados por verdaderos profesionales. Y lo mismo nos vemos! Éste en concreto terminó siendo muy gracioso xd

Estaba yo ahí flipando un poco con los términos que usaban los participantes expertos en XP con tanto CI/CD, TDD, refactoring, CCO... cuando se abrió la ronda de preguntas y se me ocurrió preguntar si XP se podía aplicar a cualquier lenguaje de programación.
Total que leo en el chat de zoom: con cobol NO.

:-( 
Por qué??!!! Qué ha hecho el pobre cobol para merecer esto??!!

Y eso dio pie a una pequeña disertación sobre si cobol sí o no, si se podían automatizar los test en cobol, si los test unitarios eran factibles, etc etc. Y el chico que había puesto lo de "con cobol NO" tuvo que puntualizar que estaba de broma, y bueno, fue nuestro momento de gloria y me reí un montón xd

Pero entonces qué, cobol sí o cobol no? Somos compatibles con XP? Pues dejadme que os cuente...

Una de las prácticas de XP es el TDD:
Test-driven development.
Los equipos XP practican la técnica de desarrollo guiada por pruebas (TDD) que implica escribir una prueba unitaria automatizada antes del propio código (así resumido).

Vale, igual automatizado automatizado no es, depende de cuánto haya invertido la empresa en herramientas de desarrollo. 
Y a lo mejor unitario unitario no es, un poco por lo mismo, porque en el mundo mainframe todo hay que hacerlo a la carta, o casi todo, y según qué aplicación estés tocando puedes tener unos cuantos CALL y unos cuantos accesos a DB2.

Pero pongámonos en el caso fácil: un batch de tratamiento de ficheros sin DB2.
Esto es factible no? 

Pues resulta que me asignaron proyecto nuevo hace unos meses (ya sabéis, para experimentar con agile management) y de repente caigo en la cuenta de que sí, de que aquí sí hacemos test unitarios (sin automatizar eso sí), y sí hacemos la documentación primero, y sí que usamos ficheros de test estables para regresionar (este verbo creo que no existe xd) y tenemos entornos de pruebas aislados...

Mira tú por dónde!
Y en mi otro proyecto (ahora mismo estoy en una de esas situaciones extrañas de "al 50%") usamos t-tool para automatización de test, en este caso de integración, así que algo sí que se puede hacer con COBOL, no?

Pero es que hasta IBM se dio cuenta y ya existe el IBM Z Open Unit Test. Quién lo ha visto ya es otra historia. 
Si alguien lo conoce y quiere compartir su experiencia, será bienvenida.

Los avances en el mundo mainframe van lentos pero despacio, qué le vamos a hacer. Pero ahí a nuestro ritmo vamos llegando (ojalá no sea tarde).

Mientras tanto, yo ya me lo apunté para experimentar. Esperando que mi querido equipo no me mande a algún sitio lejano, empezaremos a escribir los test antes de tocar el código.

#thisistheway

No hay comentarios: