Refactorizacion En TDD

ntroducción

Durante una clase, un docente pregunto a sus estudiantes que es refactorizar , bueno algunos

contestaron que es modificar el código otros que es rehacer el código, en realidad ninguno fue

certero en contestar que era refactorizacion. Es por ello que se crea este articulo sobre

refactorizacion.

Desarrollo

Sabemos que T.D.D o desarrollo dirigido por casos de prueba, es un nuevo enfoque sobre la forma

tradicional de desarrollar software es decir primero desarrollamos las pruebas antes de codificar

cualquier cosa. Para ello T.D.D trabaja en conjunto con la refactorizacion para producir código de

calidad, entendible y fácil de documentar.

Mientras hacemos T.D.D usamos dos sombreros uno se llama codificar y el otro refactorizar,

ambos son mutuamente excluyentes es decir si codificamos no refactorizamos, y viceversa si

refactorizamos no codificamos. Bien ahora que tenemos claro el panorama veamos un simple

concepto sobre que es en realidad refactorizar. Según Kent Beck en su obra T.D.D una guía

practica nos dice: refactorizar es el proceso de hacer cambios al código funcional sin modificar su

comportamiento; en otras palabras es mejorar la estructura interna del código sin modificar su

funcionalidad.

Ahora nos viene la pregunta ¿Cual es la relación entre T.D.D y refactorizacion?. La respuesta es

simple son dos aspectos en los cuales van relacionados, el primero, Después de hacer lo mas simple

para que el test pase (quebrando una o todas las reglas en el proceso), refactorizamos para eliminar,

la mayoría si no es toda la duplicación que introducimos para que el test pase. El segundo aspecto

en el que están relacionados es que, si estamos practicando T.D.D tenemos una red de seguridad que

nos permite refactorizar con confianza.

Ahora que sabemos como están relacionados T.D.D con refactorizacion, podemos preguntarnos

¿Cuando tenemos que refactorizar?. La respuesta es simple y viene en tres partes:

• Cuando existe duplicación.

• Cuando percibimos que el código esta difuso

• Cuando detectamos código apestoso

Primero veremos al enemigo publico numero uno del buen código, la duplicación. Cuando

hablamos de duplicación nos referimos no a la sobre escritura al contrario, nos referimos ha crear

funcionalidades similares en dos partes del código, parece ser algo confuso pero veamos el

siguiente código en java.

public boolean salvar() throws IOExeption {

if(outputFile == null){

return false;

}

FileWriter lector = new FileWriter(outputFile);

peliculas.writeTo(lector);

lector.close();

return true;

}

public boolean salvarComo() throws IOExeption {

outputFile = view.getFile();

if(outputFile == null){

return false;

}

FileWriter lector = new FileWriter(outputFile);

peliculas.writeTo(lector);

lector.close();

return true;

}

En este ejemplo es evidente la parte duplicada del código, al refactorizar eliminamos el código

duplicado de la siguiente manera:

public boolean salvarComo() throws IOExeption {

outputFile = view.getFile();

salvar();

}

Llamamos al método salvar ya que este tiene la misma funcionalidad y así evitamos duplicar

código.

Ahora cuando hablamos de código apestoso nos referimos a código que no pasa el estándar mínimo

de calidad, existen varios “malos olores”, los cuales veremos a continuación.

La primera mala señal o indicador de que el código es apestoso es que carece de comentarios, una

buena y muy recomendable practica es comentar el código, en variables, en métodos e incluso en

clases.

Existe aun peores como por ejemplo la duplicación del código el cual vimos anteriormente,

continuando con los “malos olores”, tenemos la intimidad vulnerada, es cuando una clase conoce

por demás sobre el comportamiento interno de otra, para ello se debe reordenar la estructura interna

para apartar las piezas que realmente tienen que ser conocidas.

Otro “mal olor” bastante común es cuando una clase es muy grande, en tal caso debemos

preguntarnos ¿Por que es tan grande?, ¿Intenta hacer cosas por demás?, o ¿Conoce mas de lo que

debe?, en tal caso una solución factible seria usar polimorfismo, como es evidente su opuesto es una

clase floja es decir que hace muy poco o casi nada para solucionar ello hay que ver la posibilidad

...