Calidad de Código

Practiques Integración Contínua o no, creo que tus scripts de compilación deberían ejecutar también unas cuantas herramientas de calidad de código. En mi opinión este tipo de herramientas es útil tanto para controlar (y mejorar) la calidad del código en sí como para formar al equipo en una mentalidad de mejora contínua.
Yo acabo de integrar las siguientes (y la lista probablemente siga aumentando):

A esto hay que añadir que Hudson integra también el seguimiento de las tareas abiertas (TODOSs, FIXMEs, etc) que también es fundamental.

¿Qué otras herramientas utilizáis?

Posted by Juan Ignacio Sánchez Lara 11:55  

11 Comments:

  1. javi santana said...
    Una cosa peligrosa con hudson y todos estos plugins es que es difícil equilibrar los parámetros. Además, aunque todo parezca automático requiere mucho tiempo el matenerlo.

    Buena lista creo yo.
    Nacho said...
    Sí, he detectado una cosa especialmente mala. Hudson tiene tres niveles de corrección para los plugins más importantes. Básicamente, le dices cuántas faltas consideras para que el build sea óptimo, mediocre o malo. El problema es que son números absolutos (5 - 20 - 100, por ejemplo), por lo que es inevitable que haya que ajustarlos constantemente. Si al menos se pudiesen expresar en faltas por unidad de compilación, o algo así...
    Probablemente acabemos obviando dichos márgenes, y nos centremos en las gráficas, que sí son interesantes. Además, el poder buscar fácilmente las "peores" clases ayuda a localizar los peores puntos de la aplicación.
    alfredo.casado said...
    Checkstyle y PMD te sirven un poco para lo mismo, para el analisis estatico y el ajuste a la guia de estilo, yo te recomendaría que escojieses uno de los dos y le dediqueis tiempo a configurarlo para que se ajuste a vuestra guia de estilo. Si no al final te juntas con tanta grafica y tanto informe que terminas por no hacerles caso, mejor pocos pero útiles que muchos y no mirarlos.

    Otra cosa que viene despues es "cuando y quien revisa estos informes", para que esto sirva de algo hay que definir esas politicas. Por ejemplo nosotros usamos scrum, pues una de nuestras politicas es que para dar por terminado un sprint hay que revisar estos informes y verificar que todo esta en los niveles permitidos (otra cosa es definir estos niveles como comentaban antes).

    Nosotros usamos:
    chekstyle para la guia de estilo
    findbugs aporta a veces datos muy interesantes sobre buenas practicas
    cobertura para verificar la cobertura de pruebas unitarias.
    simian para el código duplicado.
    javancss para tener unas metricas del tamaño del código, lastima que no haya plugin oficial para hudson todavía (esta en proceso)
    Nacho said...
    Al menos inicialmente voy a tirar tanto con Checkstyle como con PMD. En función de cómo de bien se ajusten a nuestras necesidades, dejaré uno, otro o los dos.

    Como Scrum Master voy a hacer un seguimiento diario de ellos. Creo que si los dejamos como objetivo final no van a valer para nada, no quiero dedicarnos a refactorizar. Como ya he comentado antes, estas medidas y plugins (ya que los vamos a tener también instalados en Eclipse, al menos los disponibles) forman parte también de nuestra política de autoformación y mejora contínua. Aunque es lo ideal, por ahora no me obsesiona la idea de fijar los niveles de admisibilidad. Lo que haré será ir monitorizando el avance y avisar en caso de que nos vayamos de madre en algo, o de que vea que algo se hace metódicamente mal.

    Lo que es seguro es que al final de uno o dos proyectos habrá material al menos para plantearnos el fijar los niveles.
    pixote said...
    Hola,
    tampoco lo pintéis así de mal.
    La dificultad de parametrizar no debería de ser tanto, debería ser en función del nivel de aceptación que el dept. de calidad, de la politica de empresa imponga (claro,claro;). Cuando no se dispone de esta info entonces si es difícil decidir que poner.
    Para proyectos en MAVEN2 existe la posibilidad de configurar los módulos (subproyectos) pero no recuerdo ahora mismo a que nivel se pueden parametrizar, en relación a lo que ha comentado Nacho sobre unidades de compilación.
    Algunos plugin que utilizo, que seguro que ya conoceis:
    Crap4j, análisis de complejidad ciclica y % de cobertura de test.
    (PMD y Cobertura también te pueden dar esta info)
    Task Scanner, parsea código en busca de expresiones TODO,FIXME,XXX,etc útil para que no se olvide nada ;) el resultado también se ve por gráfica.

    Felicidades por el blog y un saludo
    Joserra said...
    Muy interesante!
    A mi se me hacen demasiadas herramientas para asimilarlas de golpe.
    Nosotros vamos con PMD/CPD, Cobertura y CheckStyle. Igual sí que probamos Crap4j, por que une la métrica de complejidad de código con la de cobertura, y es un dato interesante ahora que empezamos con pruebas unitarias. No todo debe tener 100% de cobertura, sobre todo ahora que empezamos.

    También usamos HUDSON, ¿lo integras con alguna herramienta de gestión de tareas? (Nosotros tenemos que integrarlo con JIRA)
    Un saludo
    Nacho said...
    Puede que sean demasiadas, el tiempo lo dirá. ¡Quería probarlas todas! :)

    Sí, usamos Trac. Hay un plugin para Hudson y otro para Trac, aunque su integración tampoco me preocupa mucho. Lo que sí es imprescindible (desde mi punto de vista) es la integración entre Eclipse y Trac.
    Joserra said...
    ¿con qué haces la integración? ¿mylyn?
    Yo ando buscando una integración entre JIRA y eclipse (bueno, no he buscado demasiado :D ), pero tampoco es una cuestión que se me haga demasiado imprescinsible.
    Nos arreglamos bien con el navegador en otra ventana... y el panel de scrum en la pared :)
    Nacho said...
    Sí, con Mylyn, que es un componente que ya viene de serie con Eclipse Ganymede. Es genial. Usado adecuadamente puedes conseguir trazabilidad de requisitos a código con coste 0. Nota mental: hacer un breve post sobre esto :)

    También se conecta con Jira (entre otros).
    Joserra said...
    Nosotros seguimos la trazabilidad por el mensaje en el commit a SVN, que enlazamos con la tarea JIRA.

    ¿qué ahce mylin?
    Nacho said...
    En este webminar sobre Mylyn puedes ver que lo que han pretendido es ayudar al workflow del programador. Realmente la trazabilidad la conseguimos como tú (con Trac en vez de Jira y mensajes en los commits). Mylyn lo que hace es ayudar. Por ejemplo, mete el comentario en el commit de la tarea en la que estás trabajando (sí, parece una tontería, pero es muy práctico). Sobre todo introduce el concepto de contexto de tarea. Eclipse sabe en qué tarea estás trabajando (la has seleccionado) y recuerda los ficheros abiertos en ese contexto, las horas invertidas... Además, el hecho de disponer de la tarea en el mismo IDE en vez de tener que ir a otra aplicación también es positivo.

Post a Comment