PG_C04_Conclusiones
-
Conclusión de Large Class: Para este proceso de detección se han utilizado las métricas obtenidas por SourceMeter de las clases. El BadSmell Large Class lo hemos detectado con la fórmula de la literatura: NOM + NOF > 20. Como SourceMeter no nos da estas métricas hemos usado las que consideramos equivalentes en la mayoría de los casos, pero con otra nomenclatura, NM y NOA. Tras la realización de la revisión manual de estos casos positivos veo que parece que los datos están falseados en su mayoría. No los quito porque no estoy seguro de cómo hace SourceMeter para considerar cuando es un atributo y cuando no, etc y si tiene en cuenta las clases de las que heredan. Por lo que podría tener una lógica interna, la cual desconozco.
-
Conclusión de Long Parameter List: Para este proceso de detección se han utilizado las métricas obtenidas por SourceMeter de las clases. El BadSmell Large Class lo hemos detectado con la fórmula de la literatura: NOP > 5. Como SourceMeter no nos da estas métricas hemos usado las que consideramos equivalentes en este caso, pero con otra nomenclatura, NUMPAR > 5. Tras una revisión manual de los métodos observamos que las métricas son correctas y que pasa de 5 parámetros en todos los métodos.
Para este proceso de detección de BadSmells he utilizado las métricas obtenidas por SourceMeter de los métodos. El BadSmell es Switch Statements y lo hemos detectado con la fórmula de la literatura: SCC > 10 . SourceMeter no nos da esta métrica, pero he querido utilizar la métrica CC, que si bien no es la complejidad ciclomática estricta se le aproxima muchas veces.
He podido observar lo siguiente: había ciertos métodos en los que se había calculado esta métrica y daban resultados exagerados de 6 cifras, lo cual es muy improbable. Tras examinar los métodos manualmente hemos visto que calculando la complejidad ciclomática rara vez pasaban de 10. Hemos seleccionado los que la pasaban cumpliendo la fórmula y el resto han sido descartados. Tiene toda la pinta de que SourceMeter no calcula correctamente esta métrica porque había métodos con números muy exagerados de 6 cifras y la gran mayoría con el valor 0. Muy posiblemente entre estos a 0 habría unos cuantos que pasarán de 10 y no han podido ser detectados por el mal funcionamiento de SourceMeter.
Los dos métodos presentan el problema de diseño denominado Feature Envy, que surge cuando un método se aprovecha de manera intensiva de los datos de otras clases, en vez de funcionar principalmente con los datos de su propia clase. En las situaciones de testProxyConstructor y testSimpleProxyManager, se nota un abuso en el uso de atributos o métodos de una o varias clases externas, lo que indica que una porción de la lógica aplicada en estos métodos podría estar más adecuadamente situada en las clases de las que dependen.
Este tipo de diseño suele incrementar el acoplamiento y reducir el encapsulamiento, provocando que las clases se vuelvan excesivamente vinculadas entre ellas y complicando su desarrollo autónomo. Sugerimos una redistribución de responsabilidades como posible mejora, promoviendo una estructura en la que cada clase administre su propia lógica y reduzca la interacción con otras clases al mínimo necesario.
Al no devolvernos inCode los datos utilizados para los resultados añadimos el siguiente análisis.
Las clases SCProxy, Outlink y ProtocolResponse presentan el code smell Data Class. Al analizar las clases mencionadas, se observa que:
-
SCProxy: Parece actuar como un contenedor de configuración o estado relacionado con proxies, sin implementar lógica propia significativa.
-
Outlink: Probablemente representa enlaces salientes extraídos durante el proceso de análisis, almacenando información como la URL y el texto del enlace, pero sin métodos que operen sobre estos datos.
-
ProtocolResponse: Es probable que encapsule la respuesta de una solicitud de red, conteniendo datos como el contenido, los encabezados y el código de estado, pero delegando el procesamiento de estos datos a otras clases.
Estas clases exponen sus datos a través de getters y setters sin proporcionar métodos que encapsulen comportamientos relacionados. Para su análisis nos basamos en las siguientes métricas:
- WOC (Weight of Class): Proporción de métodos funcionales públicos respecto al total de miembros públicos.
- NOPA (Number of Public Attributes): Número de atributos públicos.
- NOAM (Number of Accessor Methods): Número de métodos de acceso (getters y setters).
- WMC (Weighted Method Count): Conteo ponderado de métodos, que refleja la complejidad de la clase.
La regla en la que posiblemente se ha basado inCode para considerarlas como Data Class es la siguiente:
WOC < 0.33 AND ((NOPA + NOAM > 5 AND WMC < 31) OR (NOPA + NOAM > 8 AND WMC < 47))
Con este criterio, y con un análisis visual de la clase, las clases tienen un WOC bajo, NOPA y NOAM altos, y una complejidad baja.
Como recomendaciones para mitigar este code smell:
-
Encapsular comportamiento: Mover métodos que operan sobre los datos de estas clases desde otras clases hacia la propia clase, promoviendo una mayor cohesión.
-
Reducir exposición de datos: Limitar el acceso directo a los atributos, evitando getters y setters innecesarios, y proporcionando método
Solo hemos conseguido sacar 5 BadSmells de los 6 que se pedían. Hemos tenido verdaderos problemas para encontrar proyectos que nos devolviesen suficientes, por lo que al final nos hemos quedado con este. Así mismo hemos tenido problemas con las dos herramientas PMD e InCode, debido principalmente a la mala compatibilidad con sistemas modernos, posiblemente también por las versiones de Java y Eclipse. De hecho, nos hemos inclinado por sacar BadSmells con las métricas de SourceMeter porque varios compañeros no hemos sido capaces de poner en funcionamiento las herramientas, y hemos invertido más tiempo casi en intentar esto y encontrar proyectos adecuados que en realizar los análisis, etc. De hecho PMD no nos ha funcionado para este proyecto. Incode por el contrario a los compañeros que les funcionaba les ha ido siempre, pero tenían la limitación de las 100.000 líneas de código, por lo que cuando un proyecto grande tenía muchos BadSmells no podíamos aprovecharlo.
Por otra parte, una vez encontrado este proyecto nos ha parecido una práctica interesante, la dinámica de detectar posibles BadSmells y analizarlos manualmente para detectar falsos positivos es interesante. Si que echamos de menos que en InCode diese más información adicional para poder verificar manualmente que el análisis que hace es correcto y en qué se basa exactamente. En PMD aunque no lo hemos hecho entendemos que es una herramienta bastante potente, pero más si es usada por software que elija y muestre las reglas y sus resultados de mejor manera, como por ejemplo hace SonarQube.
¿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?
La implementación de normas cuantitativas (como NM + NOA > 20 para la Clase Amplia o NUMPAR > 5 para la lista de parámetros Largos) proporciona un criterio de detección objetivo; sin embargo, produce falsos positivos cuando no toma en cuenta el objetivo de la entidad.
Por ejemplo, en las clases de prueba SiteMapParserBoltTest (26 + 1 > 20) y BasicURLNormalizerTest (25 + 0 > 20) se respetan las reglas de Large Class solo porque recolectan una gran cantidad de casos de prueba, no porque su tamaño pueda afectar la conservación del código productivo. Asimismo, constructores como SCProxy.SCProxy(...) (9 parámetros) exceden el límite de la lista de parámetros Long debido a requerimientos de configuración, no a un diseño interno deficiente.
Así pues, a pesar de que las métricas puedan identificar automáticamente entidades que superen los límites establecidos, resulta esencial incluir filtros contextuales (por ejemplo: pruebas vs. código productivo) y revisiones manuales. Solo de esta manera se previene categorizar como defectos circunstancias en las que el alto número de líneas, parámetros o complejidad ciclológica está justificado de manera funcional, asegurando que los límites funcionen como orientación y no como veredicto absoluto.
Cuando hablamos de Bad Smells hacemos referencia a malas prácticas operativas y estructurales dentro de un código que es funcional. Por lo que el objetivo final no es la depuración de código.
Aun así, un código que es funcional puede tener defectos a la hora de evaluar comportamientos anómalos o no esperados, que es posible que puedan detectarse. Además, nos puede ayudar a la reutilización eficiente de código en diferentes proyectos, que permitan evitar fallos en modificaciones posteriores.
A pesar de esto, hay que asegurarse de que las herramientas que dan las métricas desprendan resultados que sean de confiables, ya que la experiencia nos ha mostrado que, por ejemplo, la respuesta de SourceMeter tiene que ser revisada.
¿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 todos los fallos en el código pueden ser detectados a través de indicadores cuantitativos, ya que numerosas malas prácticas o dificultades de diseño son de naturaleza cualitativa y se basan en el objetivo y la claridad del código.
Por ejemplo, en la práctica identificamos, a través de métricas diversas, clases que excedían el límite de Large Class (NM + NOA > 20), tales como Metadata (26 + 0) o CookieConverterTest (21 + 0), aunque ambos son pruebas o contenedores de datos de prueba cuyo tamaño está justificado y no constituyen un defecto real.
Igualmente, procedimientos con una amplia gama de parámetros, como el constructor SCProxy.SCProxy(...) (NUMPAR = 9), violaron la regla de Long Parameter List (umbral > 5), aunque tal gran número de parámetros se debe a la necesidad de inyectar diferentes dependencias y no a un diseño incorrecto.
Estos ejemplos evidencian que existen fallos—como un código complicado de comprender debido a un mal nombre, lógicas duplicadas delicadas o infracciones al patrón arquitectónico—que no se manifiestan en métricas numéricas y necesitan ser revisados manualmente o utilizando instrumentos de análisis semántico.
Respecto a la herramienta InCode ¿qué fortalezas y debilidades idénticas en su funcionalidad relaciona con la detección de defectos de código?
De esta herramienta vemos más debilidades que fortalezas. Como fortaleza, simplemente diría que es automático y que puede detectar ciertas métricas. Como debilidad diría que está muy desfasada y realmente incompatible con sistemas modernos, ya que a veces funciona y de repente falla en una nueva ejecución sin haber cambiado nada. Nos ha costado bastante ponerla en marcha por su antigüedad. Y además sólo detecta muy pocos defectos, al menos en su plan de evaluación.
Respecto a la herramienta PMD ¿qué fortalezas y debilidades idénticas en su funcionalidad relaciona con la detección de defectos de código?
Si bien no lo hemos podido probar vemos que PMD consigue encontrar infinidad de defectos. Esto es bueno, además se pueden esconder las reglas que no nos interesan. Lo malo que tiene son los problemas que hemos visto para hacerlo funcionar. Como hemos comentado anteriormente en las conclusiones globales, entendemos que es una herramienta con mucha potencia, pero que software de terceros como SonarQube la sacan mucho más partido.