Skip to main content

Ideas y mejoras por implementar

Este documento reúne ideas, mejoras y propuestas técnicas para la evolución del proyecto, organizadas por categorías.
Las iniciativas aquí listadas pueden derivarse en tareas, historias de usuario o spikes técnicos.


1. Arquitectura y organización del código

1.1 Migración a monorepo (NX)

Contexto:
El repositorio actual contiene múltiples módulos y un crecimiento acelerado de archivos, lo cual dificulta mantenimiento y escalabilidad.

Propuesta:
Evaluar una migración a NX para convertir el proyecto en un monorepo estructurado.

Beneficios esperados:

  • Mejor segmentación por dominios y módulos.
  • Builds y deploys más rápidos con caching inteligente.
  • Control más claro sobre dependencias internas.
  • Estructura más limpia para futuros módulos.

Consideraciones / riesgos:

  • Amplify requiere ajustes para reconocer un monorepo.
  • Validar pipelines y rutas de compilación.
  • Es necesario hacer pruebas de funcionamiento completas tras la migración.

2. Documentación y procesos

2.1 Documentación formal con Docusaurus

Objetivo:
Integrar la documentación técnica, funcional y de procesos en Docusaurus.

Líneas de trabajo:

  • Documentación del código (arquitectura, módulos, decisiones técnicas).
  • Documentación de features (requerimientos, flujos, pantallas).
  • Manuales internos para devs (plantillas de historias de usuario, PR y README).
  • Crear un mapa del sitio dentro de Docusaurus para navegación general.

2.2 Historias de usuario y Pull Requests obligatorios

  • Definir un proceso estándar para historias de usuario.
  • Estructurar PRs con las plantillas definidas.
  • Cualquier cambio debe:
    • Adjuntar su historia de usuario.
    • Abrir PR.
    • Seguir la plantilla establecida.

2.3 Estandarizar estructura de commits

Posibles estrategias:

  • Conventional Commits (feat:, fix:, docs:, etc.)
  • Generación automática de changelogs.
  • Facilitar releases controlados.

3. Pruebas y calidad del código

3.1 División del trabajo de pruebas

Propuesta:

  • Unitarias → responsabilidad de cada dev al implementar su feature.
  • E2E → responsabilidad del dev encargado de documentación/QA.

3.2 Herramientas

  • Unitarias: Jasmine / Karma (Angular)
  • E2E: Cypress para validar flujos completos y pruebas visuales si aplica.

3.3 Integración CI/CD futura

  • Validar pruebas automáticas antes del deploy.
  • Reglas para bloquear merges sin tests.

4. Exploración tecnológica

4.1 Evaluar integración de Vue con Angular

Estado: idea en exploración.
Se evalúa si:

  • Vue podría mejorar la flexibilidad del front.
  • Existen limitaciones de integración Angular + Vue en entornos corporativos.
  • El costo/beneficio es viable.

4.2 Revisión de nuevas librerías o frameworks de UI

  • Evaluar reducción de complejidad en components.
  • Buscar alternativas a componentes repetitivos actuales.

5. Gestión y asignación de actividades

5.1 Reasignación y definición de responsabilidades

Propuesta de roles por área:

ÁreaResponsableDescripción
Actualización de dependenciasDev asignadoRevisión periódica + impacto
Pruebas unitariasDev por featureAsegurarlas antes de PR
Pruebas E2EQA / Dev documentalFlujos completos
Documentación (Docusaurus)Dev documentalFuncional + técnica
ArquitecturaTech LeadRevisión estructura general
Mapa del sitioDev documentalEstructura navegable en Docusaurus

5.2 Seguimiento de dependencias

  • Revisar Dependabot.
  • Revisar seguridad de paquetes.
  • Plan de actualización trimestral o mensual.

6. Ideas adicionales por explorar

  • Implementar un tablero visual en Docusaurus para roadmap interno.
  • Integrar Storybook para centralizar componentes UI.
  • Automatizar generación de documentación a partir de comentarios TS.
  • Crear script interno para validar estructura de módulos.
  • Mejorar performance con lazy loading y módulos dinámicos.
  • Analizar migración de Node 16 → 18/20 dependiendo del soporte AWS.

7. Experimentos por ejecutar

Experimento 1: Migración gradual a monorepo

  • Hipótesis: La estructura NX reducirá tiempo de build y facilitará la mantenibilidad.
  • Cómo medir: Comparar tiempos de build, complejidad de PRs, dependencias y estructura final.
  • Resultado: (pendiente)

Experimento 2: Prototipo de documentación feature → Docusaurus

  • Hipótesis: La documentación cercana al código mejora onboarding y calidad.
  • Cómo medir: Uso, claridad, retroalimentación del equipo.
  • Resultado: (pendiente)