Refactoring

El Refactoring es una práctica fundamental en el desarrollo del software, que sin embargo, se deja de lado demasiado a menudo debido a las presiones para cumplir con las fechas de entrega.

No es algo “opcional” que se puede dejar “para cuando haya tiempo”. Al contrario. Es igual a la limpieza del taller mecánico, debe realizarse constantemente, sino se empezarán a perder piezas, herramientas, y la productividad se verá afectada gravemente. Nuestro proyecto comenzará a caer víctima de la ley de la entropía.

¿Y qué es el refactoring? Muy fácil. Consiste en realizar mejoras al código sin modificar su funcionalidad externa. Es decir, sin que el usuario de nuestro código tenga que enterarse de que hubo un cambio. No consiste en introducir nuevas funciones ni arreglar errores, sólo estamos optimizando lo que ya existe.

Quizás sea mejor ilustrar con un ejemplo muy simplificado, uno de mis refactorings favoritos, proveniente del catálogo de Martin Fowler.

Reemplazar Condicionales Anidados con Guards

Es bastante frecuente encontrar código como este:

public bool AvanzarSemaforo()
{
    if(_semaforo.Estado == EstadoSemaforo.OK)
    {
        if(_semaforo.Color != ColorSemaforo.Rojo)
        {
            if(_semaforo.Color != ColorSemaforo.Amarillo)
            {
                return true;
            }
        }
    }

    return false;
}

El problema con este antipatrón que ha sido llamado “punta de flecha” [1] por la forma que toma el código, es que aumenta innecesariamente la complejidad del código, dificultando su comprensión a la hora del mantenimiento.

La solución consiste en invertir las comparaciones booleanas, colocando los casos excepcionales al principio del método en forma de guardas y a continuación el camino normal de la ejecución:

public bool AvanzarSemaforo()
{
    if(_semaforo.Estado != EstadoSemaforo.OK
       || _semaforo.Color == ColorSemaforo.Rojo
       || _semaforo.Color == ColorSemaforo.Amarillo)
    {
        return false
    }

    return true;
}

Como podemos ver, el método es ahora mucho más breve y comprensible.

Programas como Resharper automatizan este tipo de refactorings e incluso los sugieren automáticamente. Sin embargo no es difícil hacerlo de forma manual, siempre teniendo cuidado de no alterar la funcionalidad original, que es el objetivo fundamental de todo refactoring.


[1] Sean Chambers, Simone Chiaretta: 31 Days of Refactoring. pág 38. Enlace: http://lostechies.com/e-books

Published by Orlando Ramírez

Software Engineer. Munich, Germany. https://www.linkedin.com/in/orlandoramirez1

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s