Skip to content

Iteración de HUs

Jump to bottom
Kran edited this page Jun 8, 2026 · 3 revisions

Modifiability:

A favor de la escalabilidad, legibilidad y la mantenibilidad del proyecto se decide separar index.js en multiples carpetas y queda como se ve a continuacion:

/backend
  /config        (Configuración global. Ej: CORS, Multer)
  /controllers   (Manejan requests/responses. Ej: login(), createLoan())
  /middleware    (Auth, validación, autorización)
  /routes        (Definición de endpoints. Ej: router.post('/login'))
  /uploads       (Archivos subidos por los usuarios)
  /utils         (Funciones auxiliares. Ej: simulateLoan(), isLuhnValid())

  db.js          (Conexión a PostgreSQL)
  server.js      (Punto de entrada de la aplicación y anterior index.js)
  package.json  
  package-lock.json

Este cambio no está asociado directamente con una HU pero es considerado relevante para tener un progreso mas ordenado y a continuacion se nombrarán los beneficios obtenidos.

Beneficios

  • Separación de responsabilidades entre rutas, controladores, middleware y utilidades.

  • Reducción del tamaño y complejidad de server.js.

  • Mayor facilidad para agregar nuevas funcionalidades sin modificar componentes existentes.

  • Mejor mantenibilidad y legibilidad del código.

  • Mayor facilidad para realizar pruebas unitarias e integración de nuevos desarrolladores al proyecto.

  • Responsable : Alejandro

  • Tiempo empleado : ~5 horas

Performance - Latency

Dado que seguimos en fase de pruebas y no tenemos claridad cuando será desplegado el proyecto, hemos decidido mantener el estado actual y enfocarnos en desarrollar las funcionalidades principales que nos solicitó el cliente y después procederemos con la optimización como está indicado. De igual manera, nos basaremos en esto para seguir desarrollando de forma más optimizada aunque de momento no haremos cambios a lo que tenemos e implementaremos este cambio que no es de gran calibre pero ayudará mucho al rendimiento:

Ejecutar scripts SQL para crear índices en las columnas de mayor consulta (rut, email, user_rut).

Este será desarrollado en la rama Performance-Latency donde haremos lo cambios y una vez pase de manera correcta la fase de pruebas haremos el Pull Request. El commit base será el c9c53c8.

Deployability

Es importante que los datos de los clientes no se pierdan por cada actualización e implementación nueva que realicemos, por lo cual tenemos que implementar los siguientes cambios:

// 1. Backend: Usar Knex.js para migraciones versionadas
exports.up = (knex) => {
  return knex.schema.createTable('users', table => {
    table.text('rut').primary();
    table.text('email').notNullable().unique();
    table.timestamps(true, true);
  });
};

exports.down = (knex) => { return knex.schema.dropTable('users'); };

# 2. Pipeline: .github/workflows/deploy.yml
name: Deploy
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Run tests
        run: npm test
      - name: Build and Push Docker image
        run: |
          docker build -t myapp:${{ github.sha }} .
          docker push myapp:${{ github.sha }}

Realizar este cambio nos permitirá mantener los datos del cliente y no perder nada de información por cambios que hagamos que necesiten un re-despliegue del sistema. Para mantener una versión base utilizaremos la rama Deployability-Correction donde haremos lo cambios necesarios, el commit base será el c9c53c8.

Beneficios

  • Se mantendrán los datos de los clientes.
  • Actualizaciones no destructivas.
  • Despliegue no destructivo.

Security

Es importante realizar estas mejoras para que los datos que recibimos no se vean comprometidos de ninguna manera, porque estamos trabajando con clientes que confían en nosotros.

Cambios necesarios para mejorar: Validar que JWT_SECRET tenga suficiente entropía, ocultar la carpeta de uploads detrás de un endpoint autenticado (o usar AWS S3), e implementar un limitador de peticiones (express-rate-limit) en el endpoint de login. Estos cambios serán implementados en la rama Security donde haremos las mejoras y el commit base será el c9c53c8.

Beneficios

  • Mayor confianza.
  • Mayor credibilidad de la plataforma.
  • Mayor seguridad.

HU001: Simulación de préstamo

Basado en los tests realizados a la API determinamos que esta HU debe ser modificada para mejorar su funcionamiento, este resultado lo obtuvimos a partir del siguiente test:

En el "test_manejo_amounts_invalidos" hubo una prueba fallida a la hora de intentar un amount negativo, pues se esperaba que la aplicación arrojara un error dado que no es posible calcular cuotas a partir de montos negativos, pero en su lugar los calculó de igual manera, lo cual es un comportamiento que se debe corregir.

Para solucionar este problema hemos creado la rama correción-hu001-simulacion-de-prestamo en donde realizaremos la corrección del problema para que el sistema se comporte como esperamos. Para poder comparar la versión base de la rama será el commit c9c53c8 el cual después compararemos con los cambios realizados.

Clone this wiki locally