Cobol VS Java: vuelve el debate

Hola amigas y amigos del Consultorio Cobol.

Como sabéis, hace tiempo que no escribo artículos de COBOL porque hace ya un tiempo que no programo. Pero es que ahora ni siquiera trabajo en un proyecto COBOL. Me he cambiado de bando...

Últimamente estoy trabajando con equipos Scrum que programan en java (o algo parecido), con su control de versiones con Bitbucket, sus branchs y demás.

El caso es que cada vez que digo: 

"recordad que lo prioritario es completar el sprint goal. Si terminamos lo nuestro, vemos de ayudar a los demás para asegurar que cumplimos el sprint goal."

Me responden: "es que no podemos trabajar más de una persona en un ticket."

Y si digo: "vale, pero hay 2 tickets." 

Entonces me dicen: "no, es que todos afectan a la misma clase. Solo puede tocar uno."

Y claro, yo que no estoy metida en la parte técnica, y que además soy de cobol-mainframe, no lo entiendo del todo.

Porque en cobol, recuerdo perfectamente repartirnos los programas (y rutinas) que había q tocar/crear. Incluso una persona podía hacer el JCL (en la versión Java el equivalente imagino que será un script) y otro el programa. O si había que tocar alguna tabla para añadir datos (parametría por ejemplo) lo podía hacer otra persona. 

Y sí, claro que para implantar/testear teníamos que ponernos de acuerdo si eran cosas enlazadas, pero podíamos trabajar varios en la misma funcionalidad. Digamos que el código estaba lo bastante troceado como para poder trabajar varios a la vez.

Eso ayudaba mucho a trabajar conjuntamente en el objetivo del sprint (cuando alguien terminaba, podía ponerse a ayudar al resto).

Entonces yo me pregunto, ¿esto es una cosa de la aplicación en cuestión con la que trabaja mi actual equipo? ¿Es que el código no está bien hecho y por eso todo está metido en el mismo "archivo"?

¿Es porque no estamos dividiendo bien las features? ¿O soy yo que no me entero?

Otra cosa que me dicen es que claro, que si cada uno se crea una branch, luego hay conflictos. Y yo me pregunto, ¿y eso es un problema? Te detecta los conflictos a la hora de hacer el merge y los "resuelves", ¿no?

¿Tan complicado es o es que buscamos la comodidad?

Por favor java developers, arrojad algo de luz... Mi objetivo sólo es terminar las cosas en curso antes de empezar otras nuevas...

#thisistheway

La beca COBOL (agilecobol)

 La famosa beca COBOL.

¿Qué cobolero no la ha vivido? Alguno hay, pero seguro que a muchos os suena esa famosa formación inicial de semanas o meses, antes de sumergirte en el mundo de la programación cobol.

El año pasado tuve mi primer contacto como formadora en una beca cobol. Me tocó la "parte 2" con COBOL y DB2.

Era mi primera vez y como el covid aún andaba por ahí me tocó dar toda la formación en remoto, sin más herramientas que una reunión de Teams.

Al segundo día supe que aquello no marchaba bien. En una llamada con 8 personas, los alumnos perdían el "preguntarle al compañero". Perdían el ayudarse entre ellos. Y tenían que escuchar cómo yo iba resolviendo los problemas de cada uno. Era un caos.

Pero no hay nada mejor que la necesidad. Si los que llevan tiempo en esto no hacían más que decir que lo mejor para aprender a programar era hacer Pair Programming, pues había que intentarlo.

Preparé una pequeña presentación para explicar en qué consistía y elegí las parejas (fuimos haciendo cambios de pareja a lo largo de la semana).

Et voilà! El ánimo subió, los ejercicios salían más rápido, yo seguía pasándome por sus reuniones a dos cuando me necesitaban y todo el mundo le pilló el punto en un instante.

Formación salvada.

Este año he tenido otra oportunidad de participar como formadora en una beca cobol, pero esta vez en presencial.

Qué diferencia. Echaba taaaanto de menos la pizarra y los rotuladores... xd Y ver la cara a la gente. No hay nada como verle la cara a alguien para saber si está en dificultades sin que diga nada.

En la anterior beca había aprovechado para hacer una retrospectiva sobre la formación y así detectar puntos de mejora para la siguiente. Y en ésta me apliqué el cuento. Por ejemplo "mucha teoría seguida sin ver nada de práctica al principio", pues nos hacemos un "Hola mundo" el primer día y desde ahí avanzamos.

Esta vez no hubo pair programming así que pude comparar las dos situaciones y sacar conclusiones:

1. Enseñar en presencial gana de calle a enseñar en remoto.

Poder pintar en la pizarra, poder señalar con el dedo (en la pizarra o en el proyector), poder ver la cara de la gente que no consigue que su programa compile... Podría dar 1000 razones.

2. Se puede enseñar sin Pair Programming (obvio), pero.

- Trabajando por pares consigues que todo el grupo avance a la vez (o casi xd). El que lo pilla más rápido arrastra al que lo pilla más despacio, y al revés, se frena a los "demasiado rápidos" para mantener un ritmo sostenible.

- Trabajando de manera individual, tienes al que va al doble de velocidad que el otro. Y lo tienes que entretener con otra cosa mientras los que van más despacio terminan.

- Aunque siempre se preguntan entre ellos, no aprenden tanto unos de otros.

- Los que terminan rápido se ponen a hacer "otras cosas" y dejan de estar centrados en la formación.

3. Hay que adaptar las formaciones a los tiempos que corren.

Lo que aprendí en la primera beca me sirvió para esta última. Mucha práctica, teoría después de la práctica y no antes, deja que fallen y corrige después...

¿Qué os hubiese gustado encontraros en vuestra beca COBOL? ¡Os leo en comentarios!

#thisistheway

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