Code Smells: Hay algo en ese código que me huele mal.

Hay que entender que si un proyecto de software tiene cierto éxito muy probablemente vaya a cambiar, y las personas que vienen detrás agradecerán que el código sea fácil y seguro de modificar.

Miguel A. Gómez · Seguir2 min read · 27 Jul 2023

Vaya, hay algo en este código que me huele mal

Malos olores del código.

Tufos del código.

Hediondez del código.

¿Hediondez?

¿Quién habla así? Estos de Wikipedia…

Código que huele.

Código que apesta.

Nadie sabe muy bien cómo traducir el término code smell.

Pero bueno, eso no es importante.

Lo que sí es importante es entender su razón de ser.

El término no es nuevo, apareció por primera vez en el libro de Refactoring de Martin Fowler, allá por el año 1999.

En ese libro, Fowler escribió un capítulo junto a Kent Beck en el que describen un catálogo con 22 code smells.

El catálogo ofrece ejemplos de código potencialmente problemático, a menudo relacionado con la cohesión y el acoplamiento.

Código que muestra carencias del diseño en cuanto al mantenimiento.

La metáfora viene a decir algo así:

“Vaya, hay algo en este código que me huele mal”.

Y a cada olor le dan un nombre:

Obsesión por primitivos, cirugía a cañonazos, código duplicado, comentarios innecesarios, clases grandes, generalidad especulativa y unos cuantos más…

En 2018, en la nueva edición del libro, añadieron añadieron algunos y renombraron otros.

Pero eso no son todos los que hay, ni todos los que son.

Dependiendo del stack que uses también puedes encontrar diferentes smells.

Tranquilo, no tienes que saberlos todos de memoria, debemos tener en cuenta que son heurísticas y no axiomas.

Cómo dice Carlos Blé:

“Habrá situaciones en las que una supuesta pestilencia sea en realidad la manera más simple de resolver un problema y, por ende, la más conveniente”.

Verás.

Aún hoy en día sigo escuchando a muchos developers decir que si el código funciona está bien, que cada uno hace las cosas a su manera.

“Funciona, eso es todo lo que importa”.

Pero cuando le dices:

“Show me the code”, empieza el olor…

Hay que entender que si un proyecto de software tiene cierto éxito muy probablemente vaya a cambiar, y las personas que vienen detrás agradecerán que el código sea fácil y seguro de modificar.

Si escribes código que sólo “funciona”, que solo resuelve el problema, estás dejando el trabajo a medias.

Lo que hoy aporta valor, en el futuro no lo hará.

Más bien restará.