Este proyecto es un apoyo docente de la asignatura. Cada release liberada corresponde al código utilizado en clase del curso indicado
Java
Maven
GitHub
GitHub Actions CI
Sonarcloud
Better Code Hub
Slack
Spring-boot
Heroku
OpenAPI
- Clonar el repositorio en tu equipo, mediante consola:
> cd <folder path>
> git clone https://github.com/miw-upm/apaw
- Importar el proyecto mediante IntelliJ IDEA
- Open Project, y seleccionar la carpeta del proyecto.
- Marcar Create Project from external model, elegir Maven.
- Next … Finish.
🎥 Videos (www.youtube.com/miw-upm)
- Lista de reproducción: APAW. Arquitectura y Patrones para Aplicaciones Web
La practica consiste en ampliar de forma colaborativa una aplicación: https://github.com/miw-upm/apaw-practice.
NOTA. Todo el software deberá estar en ingles.
Por ejemplo: story:sport
, story:team
... no puede haber repetidas. En todos los issues# creados, se deberá asociar
dicha etiqueta, además de la etiquita de estimación (puntos). Los nombres de los paquetes, deben coincidir exactamante
con la historia, ejemplo, story:winter-games
, paquete: winter_games
.
Crear un 1️⃣ issue# (por ejemplo: Team model). Debe colocarse el diagrama de clases del modelo en los detalles del issue y debe estar siempre actualizado. Para resolverlo se utilizará un flujo de trabajo ramificado, y una vez finalizado e incorporado a develop y añadido el tiempo consumido, se debe avisar al profesor mediante Slack dando en el mensaje privado la url del issue, si es correcto el profesor autorizará el cierre del issue y se podrá continuar, sino, se deberán realizar los cambios.
- Crear 4 documentos. No puede haber 2 documentos, con el mismo nombre en toda la aplicación, ni dos atributos dentro de
la misma práctica.
- Cada documento: >=3 atributos, y en total >= 12 atributos, con al menos uno LocalDateTime o LocalDate, Boolean y uno numérico (Integer, Double, Long o BigDecimal).
- Los atributos para manejo de dinero deben ser BigDecimal.
- Relaciones necesarias: 1..n, n..1 y n..n.
- Crear el modelo de entidades.
- Crear los DAOs (Repositorios).
- Crear una clase para poblar las BD: <Story>SeederService e integrarlo con DatabaseSeederService.
- GET, POST, PUT, DELETE (0,75 ptos/end-point).
- PATCH (1 pto).
- Repartidos proporcionalmente entre el modelo.
- Los end-points deben estar 100% probados y los servicios también.
- Una vez finalizado los seis issues anteriores, se debe avisar al profesor por Slack, y el profesor añadirá :
- 8️⃣..9️⃣ issues# para realizar end-points de búsquedas. Recordar que en búsquedas, a cualquier nivel, resource, service, repository... siempre se coloca en el tipo de lo devuelto.
- 🔟..1️⃣1️⃣ issues# con la aplicación de dos patrones.
- Uso correcto del flujo de trabajo ramificado. Hasta -3 ptos.
- Adecuación de la temporalidad de desarrollo según el enunciado. Hasta -3 ptos.
- Mantenimiento de calidad del código según GitHub Actions y Sonar. Cobertura >= 80%. Hasta -3 ptos. Todos los
aspectos vistos en teoría, y poniendo espeacial enfásis en:
- Formatear.
- Herramienta del IDE.
- Líneas en blanco.
- Ordenar métodos.
- Repasar nombres de clases, métodos, atributos, parámetros y variables.
- Sencillez del código.
- Simplificar el código.
- Eliminar comentarios.
- Estructuras anidadas: <3.
- Complejidad ciclomática: <8-12.
- Métricas.
- Paquete: <20 clases.
- Clases: <500-200 líneas, <20 métodos.
- Métodos: <3-4 parámetros, <15 líneas.
- Eliminar redundancias (copy & paste).
- Eliminar código muerto.
- Tratamiento de errores.
- Calidad de la arquitectura (GRASP, SOLID, patrones...).
- Formatear.
- Gestión adecuada, completa y equilibrada (estimación, tiempo real...) durante el desarrollo. Hasta -3 ptos.
- Uso del ingles. Hasta -1 pto.
Indicar como texto en la subida:
- Nombre de la historía:
- Cuenta de GitHub:
- Nombre aparecen en los commits:
- Estimación total y tiempo total consumido:
NOTA. Acordarse de dar al botón de envío.