¿Existe alguna práctica recomendada sobre la frecuencia con la que el equipo debe revisar las métricas de calidad del código? No estoy seguro de con qué frecuencia deberíamos realizar una revisión de las métricas de calidad del código para buscar posibles problemas que deben abordarse. Estamos trabajando en ciclos de sprint de Scrum, pero no sé si Scrum brinda algún consejo.
¿Debería revisarse diariamente, semanalmente, al final de cada sprint o qué?
Estoy pensando aquí en métricas de calidad de código como la complejidad ciclomática, etc.
Desde un punto de vista técnico, las métricas de código deben integrarse en su desarrollo basado en pruebas (TDD) o pruebas de aceptación, preferiblemente de forma totalmente automatizada. Sin embargo, desde la perspectiva de Scrum, el marco no es prescriptivo.
La perspectiva correcta del marco es que recopilar y verificar las métricas de calidad de su código actual debe ser parte de su Definición de Listo. Revisar la utilidad o precisión de sus métricas debe ser una parte continua de su ciclo de inspección y adaptación, lo que significa:
Puede que esto no sea un estándar de la industria, pero en lugar de medir la calidad, estamos evitando que disminuya. Simplemente no permitimos que los programadores confirmen nada en la rama maestra, a menos que pase todos los controles de calidad. Por ejemplo, la complejidad ciclomática, que mencionaste. Ningún programador puede fusionar nada en la rama maestra, si su código tiene una complejidad superior a 5.
Estos dos artículos explican este enfoque con más detalles: La rama maestra debe ser de solo lectura y un control estricto de la calidad del código Java
En mi experiencia, las métricas no son una herramienta muy confiable para medir la calidad del código. Son útiles hasta cierto punto, si se utilizan como un indicador en lugar de una medida absoluta. Y pueden causar aún más daño si se usan sin pensar o con exceso de celo.* En última instancia, solo los desarrolladores expertos familiarizados con el código pueden evaluar su calidad. Por lo tanto, no gastaría una cantidad excesiva de tiempo tratando de "perfeccionar" las métricas automatizadas; en mi humilde opinión, la energía de los miembros del equipo probablemente se use de manera más eficiente para solucionar los bloqueadores o trabajar en tareas que generen valor.
Una vez que están configurados y adaptados a nuestras necesidades, prefiero usar criterios similares a los que @yegor256 describe en su respuesta. En mi humilde opinión, puede ser suficiente hacer una revisión completa de las métricas varias veces al año. Preferiría mirarlo desde el otro extremo de la tubería: siempre que encontremos un defecto de código (en el sentido más amplio), inspeccione cómo podría haberse evitado. Si encontramos que mejores métricas de calidad de código o diferentes criterios de evaluación lo habrían impedido, cambie las reglas en consecuencia.
* Recientemente, en uno de nuestros proyectos, la alta dirección solicitó que se solucionaran todos los problemas planteados por una herramienta de métrica de calidad de código automatizada. Y la tarea se le asignó a un desarrollador junior que la completó al pie de la letra... El resultado final fue un montón apestoso de errores misteriosos por todo el código base (misterioso hasta que nos dimos cuenta de su origen, claro).
Algunas métricas como "función ciclomática" deben verificarse y alertarse en cada confirmación, ya que pueden ser más difíciles de corregir más adelante, pero las métricas de calidad de la versión, como "sin código comentado", se pueden dejar para la revisión del código en la entrega de la versión.
Usamos Sonar CI para autoinspecciones diarias simples y ProjectCodeMeter para revisiones de código al final del sprint (lanzamiento).
Sven Amann