¿A qué huele el código fuente?

Se dice que el código huele cuando a pesar de que no se ha identificado ningún bug y su funcionamiento es correcto, está escrito sin atender a los principios de diseño del software o haciendo uso de prácticas nada recomendables.

¿A qué huele tu código?

El buen código es como el agua limpia, inodoro, así qué cuando desprende cierto olor debemos comenzar a sospechar que algo ocurre. Un código que huele puede ocultar problemas no visibles a simple vista que se manifestarán en el futuro, pero sobre todo, va a suponer un gran problema cuando nos dispongamos a realizar un mantenimiento o queramos implementar nuevas funcionalidades o modificar alguna ya existente.

Indicadores de código oloroso

A pesar de que no existe una convención para definir cuando huele el código, con la práctica y el estudio iremos afinando nuestra nariz para detectar este tipo de malas prácticas, y lo que es aun más importante, aprenderemos a no desarrollar código con olor.

A continuación dejamos una lista de las principales prácticas que hacen que el código huela, algunos puntos son olores de manual y otros en cambio son olores más sutiles.

Para organizar de alguna forma todos estos olores hemos decidido agruparlos por por nivel o ámbito con respecto a la aplicación.

Olores a nivel de aplicación

Problema Descripción
Código duplicado Código duplicado en cualquier punto de la aplicación.
Shotgun surgery
Cuando al realizar cambios en una clase estás obligado a realizar múltiples cambios en otras muchas clases. El motivo más probable es que una responsabilidad está dividida entre un gran número de clases.
Complejidad innecesaria Excesiva complejidad en los algoritmos que pueden ser escritos de forma mucho más sencilla.
Comentarios contraproducentes Innecesarios, irrelevantes, poco descriptivos o lo que es peor confusos o erróneos. Aquí os dejo un enlace dónde tratamos varios aspectos sobre los comentarios.
Tipo embebido en nombre Incluir el tipo de dato como parte del nombre de una variable o método.  Cuando el tipo cambie deberemos cambiar el nombre.
Nombres poco comunicativos Nombres de clases, métodos, funciones, constantes o variables poco expresivos, mal escogidos que no ayudan a saber de que se tratan, o aun peor, que confunden al programador.
Longitud de nombres Nombres excesivamente largos o excesivamente cortos. Es una variante del punto anterior.
Código muerto Código que ya no está en uso y que no se ha eliminado.

Olores a nivel de clase

 

Problema Descripción
Clases multifuncionales Cuando una clase es responsable de hacer múltiples cosas debemos plantearnos si esas tareas deben estar repartidas en más de una clase
Clases vagas Si no es buena idea que las clases hagan demasiadas cosas, si hacen muy pocas es posible que podamos combinarlas con otras
Clase excesivamente larga Las clases largas son difíciles de leer y añaden complejidad. Cuando tenemos esta situación deberíamos preguntarnos si podemos dividirla en más de una clase.
Intimidad inadecuada Una clase debería saber lo menos posible de otras, ¿existen clases que pasan demasiado tiempo juntas?
Excesiva exposición Ocurre cuando las clases disponen de más elementos públicos de los necesarios
Clases «brown dispacher» Clases cuyo único objetivo es delegar el trabajo en otras clases y carecen de funcionalidad propia.
Dispersión de funcionalidad Se da cuando el código está desarrollado de forma que necesitamos utilizar de múltiples clases para realizar una tarea útil, ¿podríamos hacerlo con menos clases?

Olores a nivel de método o función

 

Problema Descripción
Método excesivamente largo Existen distintas oponiones con respecto a la longitud de las funciones o métodos, pero suele haber unanimidad en el hecho de que no sean largas
Demasiados parámetros Demasiados parámetros en una función o método dificultan su lectura y recordar como se utilizan.
Líneas excesivamente largas Líneas de código excesivamente largas que dificultan la lectura y comprensión del código
Complejidad condicional La existencia de grandes bloques de lógica condicional muy probablemente pueden ser reescritos usando una mejor estrategia.
Abuso de tipos primitivos Si los datos con los que trabajas son suficientemente complejos crea una clase para ellos.
Grupos de datos Si tienes datos que continuamente aparecen juntos en la aplicación quizás deberías crear una clase para ellos, un ejemplo pueden ser datos como coordenadas geográficas.
Envidia de funcionalidad Método que hacen uso excesivo de otras clases, ¿quizás deberían pertenecer a esas otras clases?

Conclusión

Los olores en el código son buenos indicadores para medir su calidad y lo problemático que será a la hora de modificar o añadir nuevas funcionalidades. La detección de olores debe ir acompañada de un proceso de refactorización del que hablaremos más adelante.

Deja un comentario y comparte tu experiencia con el código oloroso. ¿Has desarrollado código oloroso? ¿has participado en proyectos qué olían muy mal? ¿has tenido que enfrentarte a él? ¿existen otros olores que no he incluido en esta lista?

 

 

 

 

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *