Acaba de ser publicada la versión 4.0 de SonarQube, una aplicación que permite obtener información de calidad del código escrito. En esta nueva versión han decidido sustituir en el widget Rules compliance el rules compliance index (ICR de ahora en adelante), un valor objetivo que indica el grado de cumplimiento de las reglas definidas para un perfil determinado, por el Technical Debt (TD de ahora en adelante), un valor que indica el esfuerzo a invertir en un proyecto para lograr el cumplimiento de las reglas, un valor que se calcule como se calcule considero que es subjetivo, y que depende de la habilidad del equipo de trabajo.
Considero que el ICR debería seguir presente de forma directa en el widget y en la aplicación y que el TD debería ser un dato adicional o secundario por las siguientes razones:
- El ICR es un valor objetivo, medido sobre la calidad del código real tecleado, en cuyo cálculo no intervienen valores o apreciaciones subjetivas.
- El TD es un valor subjetivo, ya que si bien depende de los mismos datos en los que se basa el ICR cuantifica el esfuerzo de corrección de los incumplimientos detectados para obtener una supuesta métrica de calidad que informa del esfuerzo medido en días u horas a invertir en el proyecto para obtener el 100% del ICR. Es precisamente esta subjetividad la que creo que disminuye su valor y utilidad como métrica, pues si bien puede ser interesante yo creo que no debería ser más que orientativa para comparaciones.
- Tanto el grado de cumplimiento de las reglas como la capacidad de la corrección dependen de la habilidad y conocimiento del equipo de trabajo. Pero a diferencia del ICR, esa subjetividad en el esfuerzo necesario para corregir un problema introduce un elemento externo al propio código escrito (la habilidad o conocimientos de un equipo de trabajo), lo que la relegaría a la categoría de estimación, no de métrica realista.
- Las métricas deben ser valores obtenidos de forma objetiva, en la que la posibilidad de subjetividad no pueda intervenir en su cálculo
- Las relaciones entre clientes y proveedores peligran cuando existe subjetividad en la forma de medir la calidad del software o cuando no se pueden cuantificar los valores, y no se pueden establecer relaciones de confianza entre ambos en las entregas de productos. Por ejemplo, es fácil y objetivo pedir un grado de cumplimiento de un conjunto de reglas (ICR) de un 90% (no voy a entrar en más detalles para no abrir una discusión que no es el objeto de este contenido), pero si ese valor se ve relegado por el TD, ¿qué le puedo exigir a mi proveedor? ¿Que el TD sea inferior a 1 día?
¿Qué opináis vosotros?
Nota: noticia enviada por Ramón Rial
Article originally appeared on javaHispano (http://www.javahispano.org/).
See website for complete article licensing information.