Check List Calidad de Software (Sprint 1) - Polnareff69/P2P-Front GitHub Wiki
Herramienta seleccionada: Pylint
Justificación de elección
Para garantizar la calidad del código y detectar errores antes de la ejecución, se eligió Pylint como herramienta de análisis estático. Esta decisión se basa en los siguientes criterios:
-
Cobertura completa: Pylint detecta errores comunes como variables sin uso, imports innecesarios, errores de sintaxis y lógica, uso incorrecto de tipos y estructuras de control.
-
Cumplimiento de estándares: Refuerza las convenciones del estilo Python (PEP8) y ayuda a mantener una base de código limpia y uniforme.
-
Configurabilidad: Permite personalizar las reglas según los acuerdos del equipo (por ejemplo, activar modo estricto o deshabilitar ciertos chequeos específicos).
-
Puntaje de calidad: Genera una puntuación cuantitativa sobre la calidad del código, útil para monitorear mejoras o regresiones.
-
Integración con CI/CD: Fácil de integrar con pipelines de automatización como GitHub Actions, GitLab CI, Travis CI, etc.
-
Compatibilidad con editores: Soporte completo en VS Code, PyCharm y otros IDEs para análisis en tiempo real.
La decisión de utilizar Pylint como herramienta de análisis estático la tomamos teniendo en cuenta estas características, destacando por su capacidad para garantizar la calidad del código y detectar errores antes de la ejecución, apoyando buenas prácticas de desarrollo. Para el equipo es una herramienta sencilla de utilizar y amigable con el desarrollador.
Configuración recomendada
Inicialmente, se está utilizando la configuración por defecto de Pylint, con planes de personalización en un archivo .pylintrc para activar un modo estricto que refuerce reglas clave.
Resultados:
Recomendaciones de estilo y correcciones Pylint
1. Nombres de clase deben usar PascalCase
# Incorrecto
class companyService:
⚠️ Error Pylint: invalid-name (C0103)
✅ Sugerencia:
# ✅ Correcto
class CompanyService:
2. Métodos sin decorador @staticmethod o @classmethod
Todos los métodos definidos no usan self ni cls, por lo tanto deberían:
- Tener el decorador
@staticmethod
⚠️ Error Pylint: no-self-use (R0201)
✅ Solución:
@staticmethod
def createCompanyWithUser(...):
...
3. Tipos incorrectos en las anotaciones
# Incorrecto
def deleteCompanies(id : uuid):
⚠️ uuid no es un tipo válido por sí solo
✅ Corrección:
# ✅ Correcto
def delete_companies(id: uuid.UUID):
4. Variables con nombres en CamelCase
# Incorrecto
companyUpdate = ...
⚠️ Error Pylint: invalid-name (C0103)
✅ Debe ser:
# ✅ Correcto
company_update = ...
5. Módulos importados no utilizados
# Incorrecto (si Product no se usa)
from Models.products import Product # unused-import
⚠️ Advertencia: unused-import
✅ Elimina la importación si no se usa.
6. Archivos sin docstring al inicio
⚠️ Error Pylint: missing-module-docstring (C0114)
✅ Solución:
"""
Este módulo contiene la lógica de servicios para las compañías.
"""
Con estos resultados pordemos hacer las modificaciones pertinentes y avanzar en el proyecto con las mejores practicas a continuacion se presenta un resumen de la calidad de software:
| Criterio | Cumplido |
|---|---|
| Se usa una herramienta de análisis estático documentada | ✅ |
| Se justifica su elección y se describen sus ventajas | ✅ |
| Se detectan y documentan errores comunes con sugerencias de corrección | ✅ |
| Falta por aplicar una configuración personalizada (.pylintrc); se hace la prueba con la configuración por defecto | ⚠️ |
| Se hace seguimiento de estilo, errores y convenciones | ✅ |
| El formateo automático con herramientas como Black está considerado | ⚠️ |
Checklist de Calidad del Software – Análisis Estático con Dart Analyzer + flutter format
Herramienta seleccionada: Dart Analyzer + flutter format
Justificación de elección
Se eligió Dart Analyzer junto con flutter format para análisis estático y formateo del código Flutter, porque:
- Integración oficial: Son herramientas nativas del SDK de Dart y Flutter, garantizando máxima compatibilidad.
- Detección temprana de errores: Detecta errores de sintaxis, uso incorrecto de tipos, malas prácticas y problemas de rendimiento en tiempo de desarrollo.
- Cumplimiento de estándares: Refuerza las mejores prácticas recomendadas para Flutter mediante el paquete
flutter_lints. - Configurabilidad: Permite ajustar reglas y configuraciones a través del archivo
analysis_options.yaml. - Formateo automático:
flutter formatmantiene el código limpio, consistente y legible sin esfuerzo manual. - Integración con IDEs: Compatible con VS Code, Android Studio y otros, mostrando alertas en tiempo real.
- Automatización CI/CD: Se puede integrar en pipelines para evitar que código con errores o mal formateado sea fusionado.
Configuración utilizada
- Se usa el paquete
flutter_lintspara aplicar las reglas recomendadas por la comunidad Flutter. - Se configura un archivo
analysis_options.yamlpara habilitar reglas estrictas y personalizadas. - Se usa
flutter formatpara formateo automático del código antes de hacer commits o en pipelines CI.
📊 Resultados y recomendaciones
| Error o advertencia típica | Descripción | Corrección recomendada |
|---|---|---|
| ❌ Nombres de clases y variables no convencionales | Dart recomienda UpperCamelCase para clases, lowerCamelCase para variables y métodos. | Ajustar nombres para seguir convención Dart. |
| ❌ Variables no usadas | Variables declaradas pero no utilizadas en el código. | Eliminar variables no usadas o usarlas. |
| ❌ Falta de documentación | Clases, métodos o funciones sin documentación/documentación insuficiente. | Añadir docstrings para mejorar mantenibilidad. |
| ❌ Uso inadecuado de tipos | Variables o parámetros con tipos incorrectos o no definidos. | Definir tipos claros y compatibles. |
| ❌ Código no formateado correctamente | Código con indentaciones o espacios inconsistentes. | Ejecutar flutter format para corregir. |
| ❌ Uso de paquetes o APIs obsoletas | Dependencias o llamadas a métodos deprecated. | Actualizar a versiones o métodos recomendados. |
Resumen
El proyecto Flutter cumple con los criterios de calidad usando las herramientas oficiales:
| Criterio | Cumplido |
|---|---|
| Se usa una herramienta de análisis estático documentada | ✅ |
| Se justifica su elección y se describen sus ventajas | ✅ |
| Se detectan y documentan errores comunes con sugerencias de corrección | ✅ |
Se aplica una configuración personalizada (analysis_options.yaml) |
✅ |
Se hace seguimiento de estilo, errores y convenciones con flutter format |
✅ |
El formateo automático con flutter format está integrado |
✅ |