Diario de Programación

 Tengo un compañero, informático, que es de los que lleva ya muchos años en la empresa. Hace ya bastante que dejó de codificar y se dedica a llevar proyectos, o sea, Power Points, Project, Word …

El otro día, a primera hora de la mañana, le veo por el pasillo con el libro "Head Firts Design Patterns" y extrañado, medio en broma medio en serio, le pregunto " ¿Qué?, ¿Te vas a poner ahora con los patrones de diseño ?". No me contestó, sólo echó una sonrisa de oreja a oreja y siguió su camino.

A última hora del día me encuentro con uno de los compañeros que trabaja con él, este sí, más joven y que todavía se dedica a programar. Extrañado por lo de los patrones de diseño, le pregunto "¿Qué pasa con Dani? ¿Se ha puesto ahora con los patrones de diseño ?". A este también se le puso una sonrisa de oreja a oreja, pero contestó … "Es que hemos tenido una demo con el cliente y necesitaba algo para calzar el proyector"

Bueno, con esta chorrada, aprovecho para despedirme el periodo de vacaciones. Buenas vacaciones a todos.

Siguiendo un poco con el post anterior, hace tiempo en Verlo para creerlo comenté un código real de una empresa con el que me había tropezado. En ese código había una clase (llamémosla Datos) con 16 atributos estáticos iguales (digamos, atributo1, atributo2, … atributo16). Pulsando un botón (uno por atributo) debía mostrarse en una ventana nueva algunas cosas relativa a uno de esos atributos. En el código había 16 clases Ventana, una por atributo, llamadas Ventana1, Ventana2…. Ventana16. La única diferencia en el código de esas clases, aparte del nombre, era que accedía a Datos.atributo1, Datos.atributo2 … Datos.atributo16

¿Qué habría pasado si hubieran usado TDD?

Supongamos que este mismo programador hubiera hecho este código usando TDD. ¿Qué habría pasado?. Pues lo evidente, habría 16 clases de test llamadas TestVentana1, TestVentana2, … TestVentana16.

Pero TDD no es sólo hacer test, es hacerlos antes. Bueno, supongamos que los ha hecho antes.

Y TDD tiene otro tercer paso, refactorizar para quitar todas las repeticiones posibles de código, incluso las menos evidentes. Bueno, no sé vosotros, pero yo, independientemente de usar o no TDD, me repatearía hacer copy-paste 16 veces de una misma clase y como ser vago a veces es una virtud, habría dado las vueltas necesarias para no hacer esto. Sin TDD se me ocurre simplemente meter los atributos en un array de 16 posiciones y en un método set() de la única clase VentanaUnica pasarle el índice de la posición que debe tratar. Es lo primero que se me ocurre, nada complejo, seguramente hay más y mejores soluciones.

Sin embargo, este desarrollador no lo ha hecho. ¿Por qué?. Se me ocurren cuatro posibles motivos:

1. Totalmente inexperto en java, un array es algo complejo de usar y lo del set() ni lo cree posible. Muchos programadores novatos tiene problemas para hacer que los atributos de una clase se vean en otra y por eso tienden a hacerlos estáticos (justo como ha hecho este señor).
2. No tiene cabeza para programar, por más vuelta que le ha dado, no se le ha ocurrido cómo evitar hacer las 16 clases.
3. Le importa tres pepinos. Para qué se va a complicar la vida si con 16 clicks de ratón (un copy y 15 pastes) lo arregla.
4. Todas las anteriores.

Bueno, pues con este panorama, ¿qué habría hecho al intentar refactorizar con TDD?

1. Ya tengo mi TestVentana1, así que hago mi Ventana1. Ahora mi TestVentana2 y hago mi Ventana2. ¡¡ Código repetido !!. ¡¡ Vamos a refactorizar !!: Imposible, java no permite hacerlo, si java no permite pasar el atributo de la clase Datos a la clase Ventana, Ventana1 y Ventana2 deben ser clases distintas. Y no te digo juntar los dos test en uno solo.
2. Buff, qué dolor de cabeza, no se me ocurre como puedo convertir dos clases distintas que manejan atributos distintos en una sola.
3. Jó, que rollo refactorizar ahora que me está funcionando, voy con los siguientes 14 pastes, que el copy ya lo tengo hecho.
4. Java no deja, no se me ocurre como hacerlo y voy a correr un montón si reaprovecho el copy para el resto de pastes.

Algo como Srcum tampoco evitaría estas cosas. En el sprint diario este señor diría "Ya tengo las ventanas de  los atributos" y todos felices. Bueno, con un poco de suerte, un día diría "tengo la Ventana1 del atributo1", al día siguiente "tengo la Ventana2 del atributo2" y alrededor del quinto día, quizás a alguien se le ponga la mosca detrás de la oreja y quiera ver qué está haciendo. De todas formas, no se tardan 16 días en hacer 15 pastes.

Una herramienta de análisis estático de código integrada en una herramienta de integración continua cantaría esto por la noche, suponiendo que cante cuando encuentra código repetido y, como hacemos nosotros, el compilado falla si no se cumple alguna métrica importante. Desgraciadamente, existe el @SuppressWarnings que la gente se acostumbra a poner por sistema, incluso antes de que cante la métrica (conozco al menos dos personas que lo hacen).

La programación en parejas también habría ayudado, salvo que la pareja de nuestro programador fuera el recién entrado al que le han asignado para que le enseñe.

Es increíble, pero si me pongo a programar de acuerdo a las buenas costumbres (TDD, DRY, métricas, clases pequeñas, código reutilizable, etc), el trabajo de programador se me hace aburrido y pesado. Pierdo más tiempo pensando cómo debería ser el código que en hacerlo.

Me divierto más cuando me lanzo a lo loco, sin pensar y programo/corrijo código según salen las cosas, veo rápidamente resultados y juego sobre ellos.

Pobre del que coja mi código después….

No tengo muy claro cómo comentar esto para que no sea muy rollo y se pueda apreciar en toda su magnitud, pero voy a intentarlo.

Hoy he estado revisando algo de código que me han pasado (de otra empresa, afortunadamente). Se supone que ese software debe hacer lo siguiente

El software tiene 16 puertos abiertos, todos ellos conectados a equipos iguales, por lo que su mensajería y comportamiento es igual en todos ellos. La idea del software es que el usuario pueda elegir uno de los puertos y hacerle un prueba apretando un botón. La prueba consiste en enviar un mensaje concreto (codificado en el código) y ver si la respuesta tarda menos de un minuto en llegar. Cuando el usuario ha elegido el puerto y pulsa el botón, se abre una ventana con un contador que comienza en 1:00 y va hacia atrás. Si la respuesta llega antes de que termine el contador, se oculta la ventana y se le dice al usuario que el puerto está bien. Si no llega, se cierra igualmente la ventana y se le dice al usuario que el puerto está mal.

¿Y cómo hace esto el software que me han pasado?

Pues se ponen 16 botones en 16 variables boton1, boton2, etc. Se guardan en otra clase 16 atributos estáticos boolean etiquetados testeandoPuerto1, testeandoPuerto2, testeandoPuerto3,…. para indicar qué puerto está bajo test. Por supuesto, los puertos también están guardados en 16 variables estáticas puerto1, puerto2, … Cada botón tiene su ActionListener (16 ActionListener) de forma que cada uno de ellos marca su atributo estático testeandoPuerto correspondiente y abre la ventana con la cuenta atrás.

Por si no fuera poco todo esto, lo bueno empieza ahora. Para la ventana con cuenta atrás se hacen 16 clases Ventana1, Ventana2, etc, una para cada botón. Estas ventanas, en su constructor, miran si se está testeando el puerto que les corresponde para arrancar la cuenta atrás. Y durante la cuenta atrás mira el puerto que le toca a ver si llega la respuesta. Por ejemplo, la Ventana7 en su constructor mirar si testeandoPuerto7 es true para arrancar o no la cuenta atrás. Y si la arranca, en la cuenta atrás se mira puerto7 para ver si llega la respuesta. Es decir, las 16 ventanas son exactamente iguales, salvo la variable testeandoPuerto y puerto, que cada ventana mira las suyas.

Y como todos sabemos que si quieres hacer algo bien es mejor hacerlo uno mismo, para la cuenta atrás no usaremos los Timer de java ni para pintar los minutos:segundos que quedan las clases Date, Calendar, SimpleDateFormat ni similares. Lo mejor es hacerse un hilo "vulgaris", guardándose previamente el currentTimeMillis(), haciendo sleeps de 1000 milisegundos, viendo el tiempo transcurrido respecto al currentTimeMillis() que guardamos al principio y multiplicar/dividir por 1000 milisegundos/segundo, 60 segundos/minuto, cogiendo los restos y las divisiones enteras para separar minutos de segundos.

Y claro, como el arrancar o no el Timer está en el constructor de la ventana y no hemos puesto métodos de arrancar/parar/resetear, pues cada vez que se pulse uno de los botones, se hace new de su ventana correspondiente, haya sido o no creada previamente, ya que si no se hace así no hay forma de rearrancar la cuenta atrás una segunda vez.

Resumiendo, 16 variables botón, con 16 ActionListener, 16 variables estáticas, 16 clases Ventanas exactamente iguales salvo por la variable que miran, y news por doquier.

Si soy bueno, puedo entender que quizás le encargaron esto a alguien que no sabe nada de java, quizás es alguien de perfil hardware que se dedica a testear los equipos con osciloscopios y voltímetros, que a su jefe se le ocurrió la brillante idea de hacer un software que ayude a testear, que a él le ha caído el marrón y que quizás incluso le han apretado en tiempo e hizo el copy-paste de las 16 clases Ventana un Domingo a las cuatro de la madrugada porque el Lunes tenía que estar todo a primera hora.

Pero hay que ver estas cosas para entender realmente lo que se dice en muchos posts y de lo que otros países más avanzados en software que España ya se han dado cuenta. Es mejor pagar el doble, el triple (o incluso 16 veces más) a un programador bueno y con experiencia, que pagar cuatro cuartos a dos o tres sin conocimientos ni experiencia ninguna. Imagino, con los conocimientos de java que demuestra, a la persona que ha hecho este código tardando dos o tres semanas en hacerlo, e imagino a algún programador bueno y con experiencia haciéndolo en una tarde, con 16 veces menos de líneas de código. La pena es que los jefes que contratan o encargan estos "marrones" al primero que pillan, no ven estas cosas, ni posiblemente quieren verlas.

 Tengo un par de compañeros de trabajo que son más o menos de mi edad y con los que llevo mucho tiempo trabajando, más de diez años. Sin embargo a mí me gusta mucho más la programación que a ellos y mucho menos los clientes que a ellos, así que más o menos en el mismo departamento, pero hemos evolucionado de forma distinta.

Yo tengo ciertas responsabilidades, pero me dedico sobre todo a hacer y revisar código con mi grupo de trabajo. Ellos han ido ascendiendo y son uno jefe "gordo" de proyecto y la otra jefa de departamento. Ambos dejaron de programar hace ya unos cuantos años y no ven el código ni de lejos.

Pero estos días surgió en un antiguo código C++ que todavía está funcionando la sospecha de un "bug" gordo y escondido, que ha sobrevivido sin ser detectado varios años.  Como no había demasiada gente disponible (ni con conocimientos de C++ ahora que todo es java), me pidieron que les pusiera un debugger y que ellos se encargaban de buscar ese "bug".

Pues el jefe "gordo" de proyecto confesó que la tarde que se pasó depurando el código es la mejor tarde que ha pasado en varios años de trabajo, harto de peleas con clientes, de controlar y ver cómo se le escapan "los dineros" más allá del presupuesto y ver cómo se le van los plazos. La jefa de departamento se la ve feliz y sonriente, ahí enfrascada con el debugger, tocando el código y viendo que va arreglando las cosas. Vino toda feliz a comentarme que había tocado el código y simplemente le había compilado.

Si es que los técnicos, en el fondo, somos técnicos y disfrutamos con las cosas técnicas, y no con las de gestión. Después de arreglar un bug, hacer un trozo de código que funciona y verlo funcionando (o simplemente que compila), nos vamos a casa felices con la sensación de que hemos hecho algo útil. Los gestores y jefe de proyecto me hace la impresión de que se van a casa con el problema en la cabeza y pocas ganas de volver al día siguiente. Eso sí, cobran bastante más.

Hace un mes aproximadamente llegó el momento de ir a las instalaciones del cliente (no a Kazajstan, sino aquí, en Madrid) para actualizar la versión de software de un sistema que está todavía en garantía. En esa versión se habían corregido una serie de incidencias que el cliente había encontrado.

El plan era ir a instalar y probar nosotros la nueva versión durante una semana. Luego, otras dos semanas probando con el cliente para verificar el correcto funcionamiento de la nueva versión y el cierre oficial de las incidencias. Así que antes de todo eso hicimos una reunión a la que se me convocó junto a otras diez o doce personas. En esa reunión se planificaron los trabajos a realizar durante esas tres semanas en las instalaciones del cliente. Y al final de la reunión todos tenían que ir allí a instalar o probar varios días … menos yo. Fui el único de la reunión al que no le tocó ninguna tarea allí. Eso sí, en la reunión me pidieron que estuviera localizable esas tres semanas e incluso hablaron de ponerme un móvil, de forma que pudieran llamarme si hubiese cualquier problema.

Al salir de la reunión me dio por pensar en todo esto: que se me llame a esa reunión, que no me hagan desplazarme, pero que quieren que esté localizable… y llegué a la conclusión de que los tengo totalmente engañados: "Todos están totalmente convencidos de que soy imprescindible, pero nadie sabe muy bien para qué".

Espero que no se desengañen y me echen…..

Hoy no es mi día. Envíe dos correos distintos, de temas distintos, a dos personas distintas. Me levanté del sitio y fuí a hacer algo (¿tomar un café?). Cuando volví a mi sitio, tenia dos correos nuevos. Las respuestas a los que había enviado. Una de las respuestas era …

"¿mande?"

La otra era …

"¿Cualo qué?"

En fin, creo que hay días en que uno no se levanta de la cama con la facilidad de hacerse entender.

Un par de cosillas que aunque no son muy de programación, ahí van.

La primera es una pequeña anécdota que me ha pasado hoy. Pregunté a mi compañero cómo se hacía "no sé qué" con log4j, que estaba seguro de que se podía hacer, pero no recordaba cómo. El tampoco sabía, así que miró en google, encontró cómo y me mando un corredo diciendo "me engañas, sí que sabes cómo se hace" y un enlace … ¡ a mi propia página de log4j en la Chuwiki !. Creo que me estoy haciendo mayor y no sólo la mano izquierda no sabe lo que hace la derecha, sino que además no se acuerda.

La otra es sobre un compañero de trabajo, que ha hecho un sitio web sobre  venta de pastores alemanes y cahorros. Aunque es fan de las herramientas de Microsoft, casi le tengo convencido para que la haga con PHP y CSS. Por cierto, si alguien visita la página y se decide a comprar un perro, que le diga que va de mi parte, que me llevo comisión  ; – )