¿Qué es la Premisa de la Prioridad de Transformación?

La mayoría de los programadores que han utilizado la práctica de desarrollo de software TDD (Rojo/Verde/Refactorización) en su ciclo de trabajo, deben estar ya acostumbrados a introducir pequeños cambios en el código en cada una de sus fases, y principalmente deben conocer los cambios asociados a las refactorizaciones que realizamos durante la última fase de TDD.

La refactorización, tal como fue definida por Martin Fowler en su libro Refactoring: Improving the Design of Existing Code (1999), “es el proceso de cambiar un sistema de software, de forma tal que no se altere el comportamiento externo del mismo pero que se mejore su estructura interna. Con el objetivo de hacerlo más sencillo de entender y barato de mantener, permitiendo que el diseño del programa mejore luego de haber sido escrito”.

Al igual que con la fase de Refactorización, durante la fase Verde también se realizan alteraciones en el código, mediante las cuales intentamos hacer que el software supere la prueba que se encuentra fallando, empleando el menor cambio posible. A estas operaciones Robert C. Martin (tío Bob) las denominó transformaciones.

Podemos pensar en estas transformaciones como la contraparte de las refactorizaciones, debido a que consisten en pequeñas variaciones en el código que permiten modificar el comportamiento externo del software pero que conservan significativamente su estructura interna. Dicho en otras palabras, las transformaciones generalizan el comportamiento del sistema sin cambiar su estructura.

Pensando en estas transformaciones, el tío Bob definió la “Premisa de Prioridad de Transformación” (sus siglas TPP del inglés Transformation Priority Premise) la cual afirma que las transformaciones poseen un orden inherente fundamental, y que al ser aplicadas en correcto orden se conduce a mejores algoritmos y se evitan interrupciones del ciclo de TDD.

Él describe esta premisa en algunas de sus charlas mediante un ejemplo de desarrollo de un algoritmo de ordenamiento, y hace notar que al violar dicho orden se conduce a un algoritmo de ordenamiento de burbuja, mientras que empleando un orden preestablecido se alcanza un algoritmo de ordenamiento rápido, el cual es mucho más eficiente que el anterior.

Basándose en sus experiencias y evaluando publicaciones de otras personas, el tío Bob llegó a la siguiente lista ordenada de transformaciones:

01	{}–>null	De no tener código alguno a código que retorna Null
02	null->constant	De código que retorna Null a devolver un valor literal simple
03	constant->constant+	De un valor literal simple a un valor literal complejo
04	constant->scalar	De un valor literal a una variable
05	statement->statements	Agregar más sentencias
06	unconditional->if	Dividir el flujo de ejecución mediante condicionales
07	scalar->array	De una variable a una colección
08	array->container	De una colección a un contenedor
09	statement->tail-recursion	De una sentencia a recursión de cola
10	if->while	De un condicional a un bucle while
11	statement->non-tail-recursion	De una sentencia a una iteración
12	expression->function	De una expresión a una función
13	variable->assignment	Reemplazar el valor de una variable
14	case/else	Añadir una bifurcación a un condicional existente

Este listado sugiere un grado de complejidad incremental en nuestras transformaciones a medida que avanzamos en él, de forma que es más sencillo cambiar una constante a una variable que el añadir una sentencia condicional. Debido a esto, se sustenta la idea de dar prioridad en su uso a las transformaciones más simples por encima de aquellas más complejas.

Como una guía para nuestro uso durante el ciclo de TDD se puede representar dicho listado con el siguiente diagrama:

Para propiciar el uso de las transformaciones más simples, cuando diseñamos una prueba, primero debemos pensar en desarrollar aquellos casos de uso que nos permitan emplear transformaciones más simples en vez de las transformaciones más complejas. Debido a que a mayor complejidad de la prueba, mayor será el riesgo que tomemos para lograr hacer que nuestra prueba pase.

Encontrarnos en una situación donde no sabemos cómo hacer que una prueba pase, es un problema que muchos hemos observado mientras realizamos TDD. Algunas veces, la causa de este tipo de impasses recae en nuestro proceso de toma de decisiones durante el ciclo de desarrollo de TDD.

La transformación más simple suele ser la mejor opción que incurrirá en el menor riesgo para crear una situación de bloqueo. Debido a que mientras mayor sea el cambio en el código, más tiempo nos tomará antes de que nuestra prueba vuelva a pasar, por lo que se produce un riesgo mayor de romper el ciclo de TDD.

Por todo lo antes expuesto, el tío Bob plantea como premisa que si se eligen las pruebas e implementaciones que empleen transformaciones que están más arriba en la lista, se podrán evitar las situaciones de impasse o interrupciones prolongadas en el ciclo rojo / verde / refactorización.

Aplicando la TPP al Kata de los Números Primos

Aplicando la TPP al Kata de los Números Primos

Podemos practicar y dominar estos conceptos aplicando esta premisa de la prioridad de las transformaciones en un problema conocido como lo es la kata de los números primos.

El objetivo de esta kata es determinar el listado de factores primos un número. Un número primo sólo puede ser dividido exactamente por sí mismo y por 1.

A continuación, realizaremos la kata de los factores primos:

1. Añadimos un Test Fallido para 1 (Caso más simple)

Nos detenemos al fallar la compilación de la prueba

1.1 Transformando para Compilar

La forma más fácil de tener éxito (compilar ahora) es crear un método con valor de retorno nulo. Esta es la primera transformación o transformación nula ({} -> null).

1.1 Transformando para Pasar el Test

Esta prueba falla porque el método primeFactorsOf devuelve null, y no una lista vacía. Para que esta prueba sea exitosa, transformaremos el valor nulo en una lista vacía.

Nuestra segunda transformación es null -> constant.

¿Acaso null no es una constante? Null también es una constante, pero Null es una constante muy especial. Es una constante sin tipo definido y sin valor. Por lo tanto, es diferente de una constante que tiene un tipo y un valor.

La transformación realizada con null -> constant hace que el código sea más general. Null es un caso muy especial, inmutable, pero una lista vacía tiene el potencial de ser general. Ser general significa que puede manejar una variedad más amplia de casos.

2. Añadimos un Test Fallido para 2

Como segunda prueba, agregamos:

assertThat(primeFactorsOf(2), is(Arrays.asList(2)));

Con lo que esta nueva prueba fallará.

2.1 Transformación – Constante a Variable

Para que esta prueba sea exitosa, generalizamos la constante new ArrayList()

Para hacer esto, transformamos la constante en una variable llamada factors. La tercera transformación es constant -> variable.

Lo que hemos hecho es una refactorización (extracción de una variable), con la cual no hemos cambiado el comportamiento en un sentido estricto. Debido a que reemplazar una constante por una variable con su valor original no altera el comportamiento del sistema. Sin embargo, nos abre la posibilidad de poder cambiar ese comportamiento. En otras palabras, cambiar una constante por una variable no es una transformación independiente, pero es una parte necesaria del proceso de transformación.

2.2 Transformación – Flujo Dividido

Una transformación que modifica una constante en una variable permite que realicemos una cuarta transformación llamada división de flujo. En la transformación de flujo dividido, una sentencia if es empleada para dividir el flujo de control del programa. Esta transformación fue habilitada por la transformación anterior. La sentencia if hizo de nuestro código algo más específico. Por lo que nos toca ahora generalizarlo.

2.2 Refactorización – Generalizando

La condición if(number == 2) fue un caso muy específico (coincidiendo con la intención de la prueba). Debemos refactorizar para manejar casos más generales.

if(number > 1) es más general debido a que está abierto a posibilidades.

3. Añadimos un Test Fallido para 3

Al incluir la tercera prueba assertThat(primeFactorsOf(3), isListOf(3)); dicha prueba fallará.

3.1 Transformación – Constante a Variable

Para lograr hacer pasar la prueba con la transformación más simple, aplicamos la transformación constant -> variable en la cual modificaremos el 2 que añadimos a la lista de factores por la variable de entrada number.

4. Añadimos un Test Fallido para 4

Para la cuarta prueba incluimos la siguiente sentencia:

assertThat(primeFactorsOf(4), is(Arrays.asList(2,2)));

4.1 Transformación – Flujo Dividido

De forma que logremos pasar esta prueba, debemos volver a hacer una división en el flujo, dependiendo si la entrada number es divisible por 2.

4.2 Transformación – Flujo Dividido Nuevamente

Aún con este cambio, otra de nuestras pruebas continúa fallando. Esto se debe a que el caso de los factores primos de 4 es exitoso, pero el caso de los factores primos de 2 debe incluir a un solo valor y no dos. Por lo que tendremos que dividir el flujo nuevamente para evitarlo.

Y con esto podremos pasar todas las pruebas.

4.3 Refactorización

En el caso de number > 1, la división es realizada dos veces. No debemos preocuparnos de ello en este momento debido a que pronto desaparecerá. No generamos ningún inconveniente si movemos la parte del segundo condicional number > 1 fuera de la primera cláusula condicional.

4.4 Refactorización

Al igual que con el código productivo, el código que compone nuestras pruebas también debe ser mantenido. Por lo que podemos refactorizar para mejorar su legibilidad al eliminar duplicación en el código.

5. Añadimos más pruebas

En los casos de 5, 6 y 7, estas pruebas funcionan correctamente si son incluidas debido a que su comportamiento se encuentra incluido en nuestro algoritmo.

6. Añadimos prueba fallida para el 8

assertThat(primeFactorsOf(8), isListOf(2, 2, 2));

La cual falla.

6.1 Transformación – If a While

Podemos aplicar la transformación If -> while de forma que pasemos la nueva prueba.

El bucle while es simplemente una forma generalizada del condicional if, por lo que if es una forma especial de la estructura while.

6.2 Refactorización

Se mejora la legibilidad del código al refactorizar el bucle while a un bucle for como se muestra a continuación.

7. Añadimos un Test Fallido para 9

Añadimos la prueba assertThat(primeFactorsOf(9), isListOf(3, 3));

7.1 Hacemos pasar con Duplicación

Añadimos la condición de división por 3 como se muestra a continuación para hacer que nuestra prueba pase.

7.2 Transformación para remover la duplicidad – Bucle más general

Hemos introducido una duplicidad en nuestro código. Podemos incurrir en estas mientras estemos trabajando en un ciclo de TDD, pero las mismas no deben registrarse en el repositorio de origen como código repetido. Esta redundancia no es una transformación, debido a que nada ha sido generalizado. Simplemente es un experimento que nos permite imaginar como debe ser la solución general.

Nuestra tarea ahora es aplicar un ciclo más generalizado para eliminar la duplicación. El código duplicado siempre es inusual y específico.

7.3 Refactorización

Mejoramos nuevamente la legibilidad al refactorizar el bucle while por un bucle for y eliminamos el condicional restante, para obtener el resultado final compuesto por dos bucles for fáciles de entender.

Conclusión

Las siguientes transformaciones fueron observadas en este ejercicio de ejemplo:

• {} -> null (1)
• null -> constant (2)
• constant -> variable (4)
• split flow (6)
• if -> while (10)

Pudimos ver mediante la kata de ejemplo una ilustración del proceso descrito por el tío Bob, y ver que al aplicar las transformaciones que propone TPP conseguimos garantizar:

• Menor tiempo en rojo (evitar el impasse)
• Descubrimiento de los puntos principales del problema
• Desarrollo de una solución genérica y con menos duplicación

La Premisa de la Prioridad de Transformación (TPP) es una de las herramientas con las que contamos para garantizar el cumplimiento de las reglas del desarrollo guiado por tests. Este listado de transformaciones no implica reglas inalterables, sino una guía para evitar los bloqueos en el ciclo de TDD, especialmente al hacer el cambio de rojo a verde.

Si te interesa conocer más sobre TPP puedes buscar el siguiente material:

• Resumen en Wikipedia
• Blog Original del tío Bob
• Conferencia del tío Bob en NDC (2011)
• Video serie Cleancoders del tío Bob (episodio 24)