Las métricas de SonarQube facilitan mantener un código limpio y fácil de entender. Por ejemplo, se pueden observar datos como la cantidad de errores, advertencias o código duplicado, lo que ayuda a corregir y optimizar el software. Esto es especialmente útil para los equipos de trabajo, ya que todos pueden ver en qué puntos se puede mejorar y así lograr un producto final de mayor calidad.

---

Overview es un tablero que muestra un breve resumen del análisis de la rama y el código que se aloja en el repositorio, con el fin de mostrar Métricas de calidad, para mejorar los estándares de codificación de nuestro producto

Muestra de forma detallada los bugs, vulnerabilities, code smell, y como se puede corregir, el enlace why is this issue?

cada issue es el incumplimiento de un patrón de codificación, pero no todo issue es un bug, saber identificarlo, interpretarlo, categorizar, es el secreto para definir de forma clara la corrección y mejora continua de la calidad de nuestro proyecto

---

Code Smell

Se refiere a señales en el código que indican que algo puede estar mal en su forma de estar escrito, aunque no genere un error directo. Es como un indicio de que el código se puede mejorar, por ejemplo, si hay funciones muy largas o partes repetitivas que hacen difícil su mantenimiento. Detectar estos olores de código ayuda a los desarrolladores a identificar áreas que pueden optimizarse para tener un código más limpio y claro.

Vulnerability

Es una debilidad en el código que podría ser explotada por atacantes para comprometer la seguridad del sistema. Es decir, es un punto vulnerable que, si no se corrige, podría permitir que se produzcan accesos no autorizados o daños. La detección de vulnerabilidades es fundamental para garantizar que el software se mantenga seguro y confiable.

Bug

Es un error o fallo en el código que causa que el programa no funcione como se espera. En SonarQube, los bugs son detectados como problemas concretos que pueden hacer que la aplicación se comporte de manera inesperada o incluso se caiga. Corregir estos errores es esencial para asegurar que el software opere correctamente y sin interrupciones.

---

Blocker

Son los problemas más graves y necesitan una solución inmediata. Pueden ocasionar fallas críticas en el sistema o incluso impedir que el proyecto continúe.

Critical:

También representan problemas muy serios, aunque quizás no detengan todo el proyecto de forma tan drástica como los Blockers. Aun así, deben resolverse con urgencia para evitar riesgos importantes.

Major

Son problemas relevantes que pueden afectar el rendimiento, la calidad o la seguridad del software, pero no de forma tan urgente como los niveles anteriores. Aun así, conviene resolverlos pronto para mantener la salud del proyecto.

Minor

Estos problemas son menos urgentes. Normalmente indican oportunidades de mejora en el código, pero no suelen poner en riesgo la estabilidad o seguridad del sistema de manera inmediata.

Info

Son avisos o sugerencias que no representan un error real o un riesgo de seguridad. Sirven para ofrecer recomendaciones de estilo o mejores prácticas, y su corrección depende más de la conveniencia del equipo que de una necesidad urgente.

Las reglas son un conjunto de patrones que definen el estilo y la consistencia del código fuente. Cada lenguaje de programación tienen sus reglas de codificación, estas se pueden amoldar a la necesidad del proyecto, uno de los beneficios que ofrece las reglas de codificación hace que todo el equipo tenga clara las reglas de desarrollo y esto hace que el proyecto tenga una calidad superior.

La métrica de cobertura de pruebas unitarias es una forma de medir cuánto del código de una aplicación ha sido probado con tests automatizados. Básicamente, nos dice qué porcentaje de las funciones, líneas o caminos del código han sido ejecutados durante las pruebas. Tener una alta cobertura no garantiza que el software esté libre de errores, pero sí ayuda a detectar problemas antes de que lleguen a producción. Lo ideal no es solo alcanzar un número alto, sino asegurarse de que las pruebas sean de calidad y realmente validen que el código funciona como se espera.

verifica funciones mediante la emulación de escenarios de negocio, en función de los requisitos funcionales. La prueba de caja negra es una forma común de verificar funciones.

la métrica de duplicación es capaz de detectar duplicaciones en tres niveles diferentes:

Es necesario conocer poo ya que podemos analizar y plantear soluciones como herencias, librerías, las cuales nos pueden ayudar en el proyecto

---

Pronosticar cuánto tiempo nos tomará realizar un cambio se basa en la experiencia, con sonarqube la complejidad será calculada 

¿Qué es esto de la complejidad ciclomática?

Imagina que tu código es un mapa. Si solo hay una recta sin desvíos, es fácil llegar al destino. Pero si hay decenas de cruces, semáforos y rotondas, es más probable que te pierdas. La complejidad ciclomática es como contar esos cruces: cuantas más decisiones tome tu código (ifs, bucles, opciones), más complejo será.

¿Por qué debería importarte?

Un código con demasiadas “vueltas” puede convertirse en un problema. En primer lugar, cuantos más caminos posibles existan, más oportunidades habrá de que algo salga mal. Imagina un error escondido en una rama de tu código que casi nadie usa: encontrarlo será como buscar una aguja en un pajar. Además, cuando el código es difícil de seguir, incluso tú mismo podrías perderte al intentar entenderlo semanas después. Y si a ti te cuesta, imagina a alguien que lo lea por primera vez. Por último, mantener o actualizar un código enredado se vuelve una pesadilla. Cada cambio puede romper algo inesperado, y el tiempo que ahorraste escribiéndolo rápido lo perderás arreglando errores.

Ejemplo práctico

Piensa en una función que decide qué hacer según el clima. Por ejemplo, si está soleado, sugiere ir a la playa; si llueve, recomienda ver Netflix; y en cualquier otro caso, propone improvisar. Este código tiene solo tres caminos posibles, así que es fácil de seguir. Pero si en lugar de tres opciones hubiera veinte condiciones anidadas, con decisiones dentro de decisiones, el caos estaría garantizado.

Consejos para simplificar tu código

Empieza por dividir tus funciones en partes más pequeñas. Si una función hace demasiadas cosas, es mejor separarla en mini-funciones, cada una con una responsabilidad clara. Por ejemplo, en lugar de tener un script enorme que valida datos, los procesa y luego los guarda, puedes crear una función para cada paso. También puedes evitar los “ifs eternos” usando estructuras como diccionarios. Por ejemplo, en lugar de encadenar diez condiciones, puedes mapear cada caso con su resultado en un diccionario y recuperar la opción directamente. Esto no solo reduce la complejidad, sino que hace el código más elegante. Otra idea clave es evitar anidar demasiadas decisiones. Si tienes tres niveles de ifs dentro de bucles, es probable que puedas simplificarlo. Y sobre todo, prioriza la claridad. A veces, un código un poco más largo pero legible es mejor que uno corto que parece un acertijo.

---