PG_C04_Conclusiones

Conclusiones aplicaciones de identificación de defectos del grupo 1

Analizar la experiencia de identificación de defectos mediante herammientas y la necesidad de revisiones humanas por expertos para evitar falsos negativos.

Conclusiones aplicaciones de identificación de defectos del grupo 2

Analizar la experiencia de identificación de defectos mediante herammientas y la necesidad de revisiones humanas por expertos para evitar falsos negativos.

Conclusiones aplicaciones de identificación de defectos del grupo 3

Analizar la experiencia de identificación de defectos mediante herammientas y la necesidad de revisiones humanas por expertos para evitar falsos negativos.

Conclusiones aplicaciones de identificación de defectos del grupo 4

Analizar la experiencia de identificación de defectos mediante herammientas y la necesidad de revisiones humanas por expertos para evitar falsos negativos.

Conclusión de general convergencia

¿Es objetiva la identificación de defectos mediante reglas de detección? La identificación es parcialmente objetiva. Las reglas se basan en umbrales numéricos (como NLOC > 100), lo cual es un criterio físico e indiscutible. Sin embargo, la regla puede identificar falsos positivos. Un ejemplo claro en esta práctica es la clase XYItemRendererState: las herramientas la marcan como Data Class porque carece de lógica compleja, pero arquitectónicamente es un objeto de estado (DTO) necesario. Por tanto, la regla es objetiva en el "qué", pero la interpretación del "por qué" sigue siendo responsabilidad del analista.

¿Ayudan las métricas a localizar defectos de código? Sí, actúan como un sistema de alerta temprana. Métricas como el Número de Parámetros (NP), la Complejidad Ciclomática (VG) o las Líneas de Código (NLOC) permiten filtrar miles de archivos en segundos para señalar dónde es más probable que existan fallos de diseño. Sin ellas, encontrar un Data Clump en un proyecto del tamaño de JFreeChart sería una tarea manual inabarcable.

¿Todos los defectos de código pueden ser localizados con métricas? No todos. Mientras que los defectos Medibles (como Long Method) son fáciles de encontrar con métricas simples, otros defectos estructurales o semánticos requieren un análisis de relaciones.

Ejemplo: El defecto Refused Bequest en AreaRenderer. Una métrica de tamaño no nos diría nada; necesitamos analizar la jerarquía de herencia y comprobar qué porcentaje de la interfaz de la superclase se está utilizando realmente. Las métricas ayudan a "sospechar", pero el diseño requiere visión contextual.

Fortalezas y Debilidades de InCode Fortalezas: Excelente capacidad visual (Pirámide de visión global). Proporciona explicaciones semánticas muy detalladas (nos dice por qué una clase es "esquizofrénica"), lo que facilita la toma de decisiones de refactorización.

Debilidades: Es una herramienta más compleja de configurar y puede generar una sobrecarga de información inicial. Detectar defectos de herencia (Tradition Breaker) a veces requiere una calibración muy específica que no siempre viene por defecto.

Fortalezas y Debilidades de PMD Fortalezas: Rapidez extrema e integración directa en entornos de desarrollo como VS Code. Es ideal para detectar rápidamente "olores" básicos de código y estilo. Su salida en formatos como JSON o CSV es muy útil para generar informes externos masivos.

Debilidades: Sus reglas suelen ser más genéricas y generan una mayor tasa de ruido (avisos de estilo mezclados con avisos de diseño). Carece de la profundidad arquitectónica de InCode para entender relaciones complejas entre grupos de clases.

Nota final: Este análisis demuestra que la calidad de software no depende de una sola herramienta, sino de la combinación del análisis métrico objetivo y la interpretación arquitectónica subjetiva. Utilizar múltiples herramientas de análisis mejora significativamente la detección de defectos, ya que permite contrastar resultados y reducir tanto falsos positivos como falsos negativos. Esta práctica refuerza la idea de que el análisis automático debe complementarse siempre con criterio técnico para obtener conclusiones fiables.