OlorEnElCódigo
Escrito por Martin Fowler
Traducido por Jorge Ferrer
Revisado por Carmen Vidal
Es un síntoma superficial que normalmente lleva asociada un problema más profundo en el sistema. El término (inglés original) fue inventado por Kent Beck mientras me ayudaba a escribir el libro Refactoring.
La definición rápida del párrafo anterior deja un par de puntos difíciles de percibir. En primer lugar un mal olor es por definición algo que es rápido de descubrir – es sniffable (susceptible de ser olido) como he comentado recientemente. Un método largo es un buen ejemplo de esto – simplemente mirando al código mi nariz se estremece si veo más de doce líneas de Java seguidas.
En segundo lugar los olores no siempre indican un problema. Algunos métodos largos son razonables. Debes mirar en profundidad para ver si hay un problema subyacente en ese caso – los olores no son inherentemente malos por si solos – son a menudo un indicador de un problema más que un problema en su mismos.
Los mejores olores son fáciles de encontrar y que la mayor parte de las veces conducen a problemas interesantes. La clases de datos (clases que son todo datos y no tienen ningún comportamiento) son un buen ejemplo de esto. Las miras y te preguntas qué comportamiento debería tener esa clase. Entonces comienzas a refactorizar para mover comportamiento dentro de ella. A menudo preguntas sencillas y refactorizaciones inicalies pueden ser el paso vital para convertir objetos anémicos en algo que realmente tiene una clase.
Una de las cosas buenas de los olores es que es fácil para gente inexperta encontrarlos, incluso si no saben lo suficiente para evaluar si hay un problema real o para corregirlo. He oido a desarrolladores jefe que escogen un “olor de la semana” y piden a la gente que los busquen y se los muestren a los desarrolladores más experimentados del equipo. Hacer esto olor a olor es una buena manera de enseñar a la gente gradualmente cómo convertirse en mejores programadores.
Gene Garcia ha publicado un resumen de los olores (CodeSmells) de mi libro en la web.


Métricas
Yo suelo utilizar métricas de código para detectar algunos olores, como el de métodos demasiado largos.
De este modo consigues detectar muy rápidamente donde están los métodos más largos de tu proyecto, sin tener que ir "buceando" clase a clase y buscándolos a mano. También suelo buscar los métodos demasiado complejos, las clases demasiado grandes, etc.
El programa que suelo usar el SourceMonitor
Saludos
JM - www.lawebdejm.com