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.
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.
Índice de Contenidos
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. Puedes echarle un vistazo a la entrada Cohesión y acoplamiento. |
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. Son clases con un alto nivel de acoplamiento. |
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 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?