Refactorización de Código: Mejora de la Calidad y Detección de Code Smells

Refactorización de Código: Conceptos Fundamentales

Definición y Objetivos de la Refactorización

El objetivo de la refactorización es mejorar el código desde distintas perspectivas sin afectar al diseño, siempre que este sea correcto.

La refactorización consiste en reestructurar el código de una clase, aplicación, etc., internamente sin modificar su comportamiento externo. Por ejemplo, en una clase, implicaría modificar el código sin cambiar su interfaz. Los motivos que pueden motivar una refactorización son múltiples, pero entre los más importantes están el mejorar el rendimiento, aumentar la legibilidad del código y facilitar su mantenimiento o ampliación.

Diferencia con la Corrección de Errores

No hay que confundir la refactorización con la corrección de errores vista en los temas anteriores. La refactorización no tiende a corregir un error, sino que sirve para mejorar el código en los aspectos antes comentados.

Detección de "Malos Olores" en el Código (Code Smells)

La refactorización generalmente arranca tras detectar un “mal olor” en el código (conocido como Code Smell). Los más habituales son:

Los 16 Code Smells más Comunes

1. Código duplicado: Partes de código idénticas o muy similares.
2. Longitud del código: Un método o función que ha crecido demasiado.
3. Clase enorme: Una clase ha crecido demasiado. Se pueden separar varios grupos lógicos.
4. Demasiados parámetros: La lista de parámetros de entrada de un método o función es tan larga que afecta a la legibilidad.
5. Envidia de funcionalidad: Un método de una clase hace un uso excesivo de métodos o funcionalidad de otra. Suele indicar que el método estaría mejor ubicado en la otra clase.
6. Grupos de datos: Datos que se están gestionando de manera conjunta en muchos sitios; se le pasan a varios métodos de forma conjunta. Al modificar unos, se cambian otros, etc. Suele indicar que deberíamos crear una clase para contenerlos.
7. Intimidad inapropiada: Una clase usa o conoce detalles internos de otra que no debería.
8. Legado rechazado:
9. Switchs para sustituir el polimorfismo o la herencia.
10. Clase vaga: Una clase que hace demasiado poco.
11. Excesiva complejidad: Código muy complejo donde existen soluciones más sencillas.
12. Identificadores demasiado cortos/largos:
13. Un uso excesivo de literales:
14. Cadenas de mensajes:
15. Clases de datos: Aunque alguna clase de datos no es un problema, no debemos caer en diseños demasiado centrados en los datos. Si vemos que hay un uso muy intensivo de determinados datos desde otras clases, generalmente se puede y debe mover el código o parte de él a la clase de datos.
16. Condiciones o estructuras condicionales excesivamente complejas: Unión de condiciones no relacionadas entre sí o subcondiciones que hacen casi imposible seguir la lógica del código.