Estándares | - Se sigue el estandar de código definido para nombrar archivos
- Se sigue el estandar de código definido para nombrar carpetas.
- Se sigue el estandar de código definido para clases, interfaces y componentes.
- Se sigue el estandar de código definido para las variables.
- Se sigue el estandar de código definido para los tipos
- Se sigue el estandar de código definido para los modelos.
- Se sigue el apartado general del estandar de código definido.
- Se cumple el estándar del archivo .env
- El código no tiene funciones duplicadas
| | |
Front end | - La interfaz gráfica está en español
- Los eventos onClick no tienen arrow functions, sino referencias a las funciones
- Todos los inputs tienen placeholders
- El botón "Editar" debe estar a la izquierda
- No hay faltas de ortografía en las interfaces
- Las acciones de "Eliminar" deben pedir confirmación
| | |
Arquitectura | - Sólo importar los módulos y/o dependencias que se utilicen en el archivo (No hay ningún import que el editor de texto y ESLint marquen como warnings de imports sin utilizar).
- El caso de uso sólo expone un método público, que debería ser el execute. Esto no aplica para los modelos.
- Se sigue la estructura de archivos definida.
| | |
Comentarios | - Todas las funciones en la capa de persistance/infrastructure están documentadas con comentarios.
- Todas las clases en la capa de persistance/infrastructure están comentadas
| | |
Consideraciones del sistema | - Las llaves secretas son guardadas en variables de entorno y no en código.
- Las rutas del caso de uso tienen la validación del rol correcta.
| | |
Compilación | - El código compila exitosamente
- El caso de uso tiene un archivo de unit testing (spec.ts) el cual pasa todas las pruebas.
| | |