jueves
jul062006
Persiguiendo la calidad del código: herramientas y
jueves, julio 6, 2006 at 3:44PM
En IBM developerWorks, Andrew Glover escribe acerca de como identificar un código "charlatán" o "locuaz" o "garrulo" (exactamente el término utilizado es garrulous, la traducción a garrulo es válida aunque no la más adecuada, pero es sin duda muy interesante empezar a hablar de "código garrulo").
Básicamente Andrew identifica que un método muy largo, o una clase muy grande, o una clase con un montón de dependencias directas con otras clases (estas tres cualidades normalmente están directamente relacionadas), es un código de mala calidad porque lo hace difícil de mantener (y comprender) y testear.
Aunque la solución obvia que implícitamente propone Andrew es la llamada "refactorización", antes de poder refactorizar es preciso detectar qué zonas del código son de mala calidad, para ello introduce conceptos como la complejidad ciclomática y herramientas tal y como PDM y JavaNCSS para detectarlos.
¿Alguien se ha visto en la necesidad de refactorizar un código ajeno?
Yo si, y aunque al principio se te ponen los pelos de punta al final es un auténtico placer ver los resultados. Yo creo que debería existir una especialización en el mundo de los programadores: los refactorizadores. Una especialización que por otra parte debería estar muy bien pagada pues vendrían a ser los poceros que trabajan en las alcantarillas del mundo del software.
¿Experiencias de uso de PMD y/o JavaNCSS o similares?
Por mi parte recomiendo la siguiente herramienta de IBM: Structural Analysis for Java, da un resultado global sobre la calidad de tu código (que algunos podrían considerar injusto) pero aparte de este dato se puede ver la calidad del código desde diferentes perspectivas.
Básicamente Andrew identifica que un método muy largo, o una clase muy grande, o una clase con un montón de dependencias directas con otras clases (estas tres cualidades normalmente están directamente relacionadas), es un código de mala calidad porque lo hace difícil de mantener (y comprender) y testear.
Aunque la solución obvia que implícitamente propone Andrew es la llamada "refactorización", antes de poder refactorizar es preciso detectar qué zonas del código son de mala calidad, para ello introduce conceptos como la complejidad ciclomática y herramientas tal y como PDM y JavaNCSS para detectarlos.
¿Alguien se ha visto en la necesidad de refactorizar un código ajeno?
Yo si, y aunque al principio se te ponen los pelos de punta al final es un auténtico placer ver los resultados. Yo creo que debería existir una especialización en el mundo de los programadores: los refactorizadores. Una especialización que por otra parte debería estar muy bien pagada pues vendrían a ser los poceros que trabajan en las alcantarillas del mundo del software.
¿Experiencias de uso de PMD y/o JavaNCSS o similares?
Por mi parte recomiendo la siguiente herramienta de IBM: Structural Analysis for Java, da un resultado global sobre la calidad de tu código (que algunos podrían considerar injusto) pero aparte de este dato se puede ver la calidad del código desde diferentes perspectivas.
in
j2se
j2se 
Reader Comments