¿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

ProblemaDescripción
Código duplicadoCó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 innecesariaExcesiva complejidad en los algoritmos que pueden ser escritos de forma mucho más sencilla.
Comentarios contraproducentesInnecesarios, 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 nombreIncluir el tipo de dato como parte del nombre de una variable o método.  Cuando el tipo cambie deberemos cambiar el nombre.
Nombres poco comunicativosNombres 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 nombresNombres excesivamente largos o excesivamente cortos. Es una variante del punto anterior.
Código muertoCódigo que ya no está en uso y que no se ha eliminado.

Olores a nivel de clase

ProblemaDescripción
Clases multifuncionalesCuando una clase es responsable de hacer múltiples cosas debemos plantearnos si esas tareas deben estar repartidas en más de una clase. Puedes echarle un vistazo a la entrada Cohesión y acoplamiento.
Clases vagasSi no es buena idea que las clases hagan demasiadas cosas, si hacen muy pocas es posible que podamos combinarlas con otras
Clase excesivamente largaLas 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 inadecuadaUna clase debería saber lo menos posible de otras, ¿existen clases que pasan demasiado tiempo juntas?
Excesiva exposiciónOcurre 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. Son clases con un alto nivel de acoplamiento.
Dispersión de funcionalidadSe 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

ProblemaDescripción
Método excesivamente largoExisten 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ámetrosDemasiados parámetros en una función o método dificultan su lectura y recordar como se utilizan.
Líneas excesivamente largasLíneas de código excesivamente largas que dificultan la lectura y comprensión del código
Complejidad condicionalLa existencia de grandes bloques de lógica condicional muy probablemente pueden ser reescritos usando una mejor estrategia.
Abuso de tipos primitivosSi los datos con los que trabajas son suficientemente complejos crea una clase para ellos.
Grupos de datosSi 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 funcionalidadMé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 código fuente.

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?

Créditos, referencias y artículos relacionados

Deja una respuesta

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