PG_C04_Conclusiones

Conclusiones aplicaciones de identificación de defectos del grupo

En esta práctica se ha utilizado la herramienta PMD y la herramienta InCode para detectar defectos de código en un proyecto de Java. Ambas herramientas tienen sus fortalezas y debilidades, y aunque pueden ayudar a identificar defectos, no son infalibles, requiriendo siempre una última revisión manual.

¿Es objetiva la identificación de defectos mediante reglas de detección? Es decir ¿la regla de detección puede identificar falsos positivos en las entidades de código?

No siempre. Aunque las reglas automáticas están diseñadas para aplicar criterios consistentes, sí pueden generar falsos positivos. Por ejemplo, la regla ConstructorCallsOverridableMethod puede marcar como defecto situaciones intencionadas y controladas por el programador. Del mismo modo, LawOfDemeter señala muchas “cadenas de mensajes” que no siempre implican un mal diseño si están justificadas por el contexto.

Por lo tanto, las herramientas ayudan a identificar candidatos a defectos, pero la interpretación final debe pasar por un análisis experto.

¿Ayudan las métricas a localizar defectos de código?

Sí, hay varios defectos de código que se pueden localizar fácilmente con métricas de código. Por ejemplo, según M. Fowler los defectos de código que se pueden localizar fácilmente son Long Method y Long Parameter List, que se detectan con las métricas NLOC y VG y NP respectivamente.

¿Todos los defectos de código pueden ser localizados con métricas de código? Indica algún ejemplo de los obtenidos después de realizar la práctica.

No. Algunos defectos requieren análisis semántico o contextual que las métricas no pueden proporcionar.

Ejemplos:

Duplicated Code: puede no reflejarse directamente en métricas, pero fue evidente al comparar clases como Rook, Bishop y Queen. Catch de excepciones genéricas (catch (Exception e)) o el uso de System.exit() no dependen de métricas, sino de reglas de buenas prácticas. Law of Demeter y defectos de responsabilidad (como clases con demasiados métodos) también requieren interpretación más allá del número.

Respecto a la herramienta InCode ¿qué fortalezas y debilidades idénticas en su funcionalidad relaciona con la detección de defectos de código?

Fortalezas:

• Ofrece una visión estructural clara del sistema.
• Útil para detectar defectos de diseño orientado a objetos como Data
  Class, Feature Envy, o God Class.
• Relaciona métricas con patrones conocidos de "code smells" según Martin Fowler.

Debilidades:

• Requiere interpretación: no todos los defectos reportados son
  realmente problemas.
• La interfaz no siempre es intuitiva.
• Puede tener problemas para procesar grandes bases de código sin
  ajustes previos.
• No muestra las métricas en las que se ha basado para detectar el defecto.

Respecto a la herramienta PMD ¿qué fortalezas y debilidades idénticas en su funcionalidad relaciona con la detección de defectos de código?

Fortalezas: PMD permite detectar automáticamente muchos code smells comunes como métodos largos, clases con demasiadas responsabilidades o nombres mal definidos. Es rápida, fácil de integrar en IDEs como Eclipse y proporciona reglas claras y configurables.

Debilidades: No detecta defectos más complejos relacionados con el diseño arquitectónico o semántico. Puede generar falsos positivos y no siempre capta el contexto del código, especialmente en casos de design smells avanzados.

Conclusión de general convergencia

Ambas herramientas permiten detectar defectos de código principalmente en proyectos Java, proporcionando dónde y porqué se considera un defecto, para que se pueda hacer una revisión manual y decidir si es un falso positivo o debe de ser corregido. Siendo herramientas necesarias de utilizar en el desarrollo software para mantener una cierta calidad.