A : alcala.chuidiang.org

B : blog.chuidiang.com

C : cinetube.es

E : eltiempo.es

F : facebook.com

G : gettertools.com

H : http://webmail.indra.es

I : imageshack.us

J : javadocx.com

L : localhost:8080

M : micro-blog.chuidiang.org

O : openxmldeveloper.org

P : peliculasyonkis.com

T : travian.net

W : webmail.indra.es

X : xmpp.org

Y : youtube.com

Me gustaría saber a cuántos no les sale facebook en la f, o youtube en la Y…..

Por cierto, en cuanto navegas un poco los resultados cambian…. y la falta de http:// en mis URL revela que uso chrome y el que no haya puesto los enlaces con enlace "pinchable", que soy muy vago

Ante ese público saco mi portátil, lo conecto al proyector que ya estaba encendido. Enciendo el portátil, aparece en el pantallón el inicio de sesión de Windows. Entro en sesión y lo primero que aparece en grande, delante de todos, mi fondo de escritorio. Sí, ese mismo, el de la foto: Windows pirated edition, service crack 2, right to copy.

En fin, eso me pasa por no ser corporativo y tener mi propio fondo de escritorio en vez de el que nos impone la empresa. Afortunadamente todo el mundo se lo tomó a cachondeo.

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.

¿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.

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….

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.

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…..

"¿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.