Hemos visto en el post precedente ‘Casos de uso – Encajar a la perfección‘ cuales casos de uso son aplicados más a menudo con una herramienta de análisis de código, y permiten conseguir el beneficio más alto:
Hemos visto en los dos últimos posts una serie de casos de uso muy frecuentes que requieren un número limitado de métricas, entre 10 y 20 de ellas. Estos casos de uso son l0s siguientes:
La pregunta en comentario del primer post es : ¿cuales son esas 10/20 métricas más importantes? Sigue leyendo
En el primer post de esta serie «Cómo elegir una herramienta de análisis de código?», hemos mencionado cuatro criterios que encontramos a menudo, aunque su importancia varía en función de lo que se quiere hacer.
Siempre me sorprenden los comparativos de herramientas de análisis de la calidad de código que pretenden definir los criterios para dicha elección, cuando la única respuesta exacta a esta cuestión es que ‘esto depende’.
Si deseas comprar un coche, por supuesto efectuarás tu elección según unos criterios que van a depender del uso futuro del vehículo. Un cupé descapotable o un coche deportivo son unos objetos por cierto muy atractivos pero poco prácticos si se trata de transportar una familia numerosa, ir a la playa con tu plancha de surf o ayudar a mudar tu vieja tía.
Lo mismo ocurre con la selección de una plataforma de análisis de la calidad de las aplicaciones.
El Año Nuevo es siempre una buena oportunidad de reanudar contactos y me ha llamado alguien a quien no había estado hablando durante bastante tiempo. Como tenemos el mismo trabajo de consultoría, compartimos nuestros puntos de vista sobre cómo van las cosas y le pregunté acerca de una empresa en la que habíamos trabajado juntos.
Me dijo que sus proyectos habían ido tan caóticos que decidieron externalizar sus aplicaciones. Reconocieron que no pudieron mantener el código fuente: demasiado complejo, muchas dificultades para implementar cualquier evolución sin generar una gran cantidad de defectos, no cumplen presupuestos y la imagen y la credibilidad del departamento TI muy dañadas.
Mi primer pensamiento fue que habían dado un gran paso adelante: saben que no saben. Sigue leyendo
Tuve un buen regalo de Navidad.
Un plugin Sonar, desarrollado por eXcentia, una empresa de la hermosa ciudad de Valencia, que conoces si te interesan los eventos deportivos como la Copa América, Fórmula 1 y Moto GP, pero también conocida por su especialidad gastronómica: la paella. Sigue leyendo
Mil gracias a todos los que contribuyeron al lanzamiento exitoso de Qualilogy: en 40 días, 300 diferentes personas (Unique Visitors) efectuaron 456 visitas y vieron 1 160 páginas (media de 2.6 páginas por visita).
Il existe de plus en plus de solutions d’analyse de code qui permettent de mesurer la qualité de vos applications. La plupart sont vendues par des éditeurs logiciels, et nous avons eu l’occasion de vérifier que ces solutions coûtaient cher à l’achat, à l’implémentation et à l’utilisation (Software jetable). Face à cela, la dernière décennie a vu la montée en puissance du monde Open Source, alternative au logiciel propriétaire.
J’entends souvent dire au sujet de solutions Open Source en matière de qualité logicielle :
Hemos visto en el post anterior cómo instalar el plugin Sonar para Jenkins. Ahora llega el momento de hacer nuestro primer análisis con Jenkins. Se centrará en el código fuente Cobol ya utilizado en nuestro primer análisis con Sonar y el Java Runner. Sigue leyendo
Después de ver cómo instalar Jenkins, este post se centrará en la instalación del plugin de Sonar para Jenkins. Sigue leyendo