¿Qué habría pasado de usar TDD?

hommer pensando en un programa softwareSiguiendo 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.

Entradas relacionadas:

Esta entrada ha sido publicada en metodologías, scrum, tdd y etiquetada como , , . Guarda el enlace permanente.

5 respuestas a ¿Qué habría pasado de usar TDD?

  1. jneira dijo:

    Yo soy obsesivo con lo de no repetir codigo y no veo mas que patrones y abstracciones por todos lados y casi lo unico que me gusta de java son las interfaces. Me tengo que refrenar pues no siempre es, no se como decirlo .., efectivo o practico abstraer y no repetir codigo. Intento seguir la regla de no abstraer prematuramente si me va a costar mas tiempo a no ser que tenga muy claro que va a haber mas de dos variantes de un algoritmo o estructura de datos.
    Hay cosas que hago siempre para que el codigo sea refactorizable en un momento dado. No soy amigo de las ides pero la verdad que lo extraer interfaz y clase abstracta ayuda bastante (aunque casi siempre pagas el no haber abstraido antes si al final lo tienes que hacer)
    Pero vamos pese a intentar cortarme dejo mas abstracciones con un solo caso que mas de dos casos abstraibles sin su correspondiente refactorizacion.
    Y no practico tdd solo intento escribir codigo decente haga antes las pruebas o despues, automaticas o manuales-depurando…

    (joer existe eso de una herramienta que te detecte repeticiones de codigo???? si encuentras algo asi avisas)

  2. Pingback: Tweets that mention Diario de Programación » Blog Archive » ¿Qué habría pasado de usar TDD? -- Topsy.com

  3. Chuidiang dijo:

    La que usamos se llama CPD (Copy Paste Detector) para java, por supuesto, http://pmd.sourceforge.net/cpd.html

    Se bueno.

  4. Angelverde dijo:

    Eso del C&P si que molesta. Apenas empiezo y me patea el higado hacerlo, así que a evitarlo.

  5. atreyu dijo:

    «y, como hacemos nosotros, el compilado falla si no se cumple alguna métrica importante.»
    Joe esa es muy buena, mejor que las reuniones y agilidades y oxtias, ¡correo-colleja al responsable del codigo y que pague los cafes del dia siguiente! Eso si que es extreme programming juasss
    Se puede hacer una metrica que sea el uso de @SurpressWarning y que no sea afectada por la anotacion 😛

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.