FIC FD TEMA 5 - Continuous Inspection

Un proyecto presenta el siguiente estado en SonarQube tras introducir código nuevo: Se detecta un Bug (condición de carrera) que puede provocar fallos en ejecución. Aparece una Vulnerabilidad (uso de una API insegura) que permite inyección de datos. Se introduce un Code smell (complejidad excesiva) que dificulta el mantenimiento. Se copia y pega un bloque de código ya existente en otro módulo (Duplicación). Pregunta: ¿Cuál es la combinación correcta entre cada problema detectado y la métrica de alto nivel afectada?. Bug (condición de carrera) → Maintainability Vulnerabilidad (API insegura) → Reliability Code smell (complejidad excesiva) → Coverage Duplicación → Securit. Bug (condición de carrera) → Reliability Vulnerabilidad (API insegura) → Security Code smell (complejidad excesiva) → Maintainability Duplicación → Coverage. Bug (condición de carrera) → Security Vulnerabilidad (API insegura) → Reliability Code smell (complejidad excesiva) → Coverage Duplicación → Maintainability. Bug (condición de carrera) → Reliability Vulnerabilidad (API insegura) → Maintainability Code smell (complejidad excesiva) → Security Duplicación → Coverage.

Fragmento analizado por SonarQube: if(a){if(b){if(c){if(d){doSomething();}}}} SonarQube detecta: Alta complejidad Código difícil de mantener Pregunta: ¿Qué tipo de issue es el principal y qué métrica afecta?. Bug → Reliability. Vulnerabilidad → Security. Code smell → Maintainability. Duplicación → Coverage.

Proyecto A: Coverage total: 92% Coverage en código nuevo: 45% Quality Gate: Coverage en código nuevo ≥ 80% Pregunta: ¿Qué ocurre?. Pasa, porque el coverage global es alto. Falla, porque el código nuevo no cumple el umbral. Pasa, porque el código antiguo compensa. Depende de los code smells.

SonarQube evalúa la calidad del proyecto utilizando principalmente análisis: Manual y dinámico. Dinámico exclusivamente. Estático y dinámico. Manual y funcional.

¿Qué problema aparece si la información de calidad no está basada en la última versión del código?. Aumenta el número de falsos negativos. Se rompe la trazabilidad histórica. Se toman decisiones sobre un estado que ya no existe. Fallan los quality gates.

¿Cuál es el riesgo principal de evaluar solo métricas globales y no métricas de código nuevo?. Incremento de falsos positivos. Penalizar a los desarrolladores por deuda técnica heredada. Ocultar bugs críticos. Aumentar el tiempo de análisis.

Un proyecto tiene muchos code smells antiguos, pero el código nuevo está limpio. Según la filosofía correcta del tema, ¿qué debe ocurrir?. El proyecto debe bloquearse hasta eliminar todos los smells antiguos. El proyecto pasa si el código nuevo cumple el quality gate. Los smells antiguos se ignoran permanentemente. Se desactiva el análisis diferencial.

¿Por qué Continuous Inspection exige que los requisitos de calidad sean objetivos?. Para que los managers puedan ignorarlos. Para evitar decisiones subjetivas de tipo “está suficientemente bien”. Para reducir el número de reglas en SonarQube. Para priorizar calidad externa frente a interna.

¿Cuál de las siguientes situaciones viola directamente una buena práctica de Continuous Inspection?. Un proyecto falla el quality gate por deuda técnica antigua. Solo se notifican issues críticos introducidos en código nuevo. La calidad se evalúa solo antes de las releases. Se muestran métricas históricas de evolución.

¿Cuál es el objetivo principal de presentar los datos de calidad en términos absolutos y diferenciales?. Comparar proyectos distintos. Medir únicamente el código heredado. Distinguir entre problemas existentes y problemas introducidos recientemente. Simplificar los dashboards de SonarQube.