SPRINT 3
Una semana
El objetivo de este sprint es mejorar la calidad del código mediante la implementación de buenas prácticas y el uso de herramientas de análisis estático como SonarCloud. Las tareas incluyen arreglos en áreas como responsabilidad, intencionalidad, consistencia y adaptabilidad del código. También se busca corregir el uso de SonarCloud, optimizar la búsqueda de direcciones y desarrollar la lógica de repartidor.
Durante este sprint, se lograron desarrollar y mejorar varias funcionalidades clave que contribuyen a la calidad y eficiencia del sistema. Primero, se integró y configuró correctamente SonarCloud, lo que permitió realizar un análisis detallado de la calidad del código. A través de esta herramienta, se corrigieron diversos problemas detectados, mejorando así la responsabilidad, consistencia y adaptabilidad del código. Además, se implementó una lógica de repartidor optimizada, que mejora la gestión de pedidos y entregas, y se mejoró la búsqueda de direcciones, agilizando el proceso para los usuarios. En resumen, el sprint ha sido exitoso en asegurar que el código sea más limpio, eficiente y fácil de mantener.
Mencionar que el desarrollo de la logica de direcciones y repartidor se alargo demasiado y no pudo completarse en este sprint pero que la funcionladidad como tal ya esta desarrollada solo queda completar con css. Tambien que no se pudieron hacer cambios en la calidad por que hubieron problemas con la configuracion de las ramas en sonarCloud y empezaran a hacerse en el siguiente sprint aunque tambien se puede poner que mientras un equipo se encargaba del desarrollo de la nueva funcionalidad el otro se ha encargado de configurar las reglas que se seguiran en el siguiente sprint para el control de calidad
Antes de corregir los errores de calidad, dedicamos un tiempo a configurar una serie de reglas que determinan que es lo que se debe marcar como un error de calidad y que no. El perfil de calidad para java que incluye sonarQube es bastante adecuado para nuestro proyecto, sin embargo, realizamos algunos cambios. El más importante fue desactivar los errores relaccionados con el uso de @Autowired.
@AutoWired es un mecanismo de inyección de dependencias automática proporcionado por Spring. Con este, Spring gestiona la creación e inyección de las dependencias necesarias en los atributos, constructores o métodos de la clase. Aunque fuera de proyectos que usen Spring esta lógica es incorrecta, para nuestro servicio si es valida por tanto todos estos errores, en nuestro servicio en concreto, no lo son.
También, desactivamos las reglas anti-injection, ya que para nuestro proyecto que al fin y al cabo, es un entorno simulado, no es necesario implementar seguridad de este tipo.
Además, activamos nuevas reglas entre las que destacan las siguientes:
La regla ".equals() should not be used to test the values of 'Atomic' classes" se refiere a que no es adecuado usar el método .equals() para comparar los valores de las clases que pertenecen al paquete java.util.concurrent.atomic (como AtomicInteger, AtomicLong, AtomicReference, etc.). Esto nos parecio correcto ya que era una regla que estabamos incumpliendo y podia ocasionar problemas de sincronización y consistencia ya que al comparar objetos atómicos usando .equals() podría no reflejarse el valor actual en un entorno multihilo, ya que el valor de estas clases podría cambiar entre el momento de la llamada a .equals() y el momento en que se realiza la comparación.
Por otro lado la regla "== and != should not be used when 'equals' is overridden" advierte contra el uso de == o != cuando se ha sobrescrito equals(), ya que esos operadores solo comparan referencias de objetos, mientras que equals() debería comparar el contenido de los objetos. Por tanto, siempre que se sobreescriba equals(), se debe usar ese método para realizar comparaciones de objetos, no == o !=.