[IV-22-23] objetivo 2

[RafaelT00]

Sobre la estructura del repositorio

• ¿He seguido las mejores prácticas en nombre de las clases y ficheros y
  disposición de los mismos?

Sobre el análisis del problema

• ¿Se ha documentado qué análisis se ha hecho sobre el dominio para decir lo
  que se ha creado?
• ¿Se ha documentado por qué se ha elegido que lo creado sea un objeto valor,
  una entidad o un agregado?
• ¿He propuesto un producto mínimamente viable, que en muchos casos será un solo
  objeto valor que no dependa de ningún otro (y que sea la base de muchos
  otros)?.

Sobre la planificación y la programación

• ¿Los issues representan un problema, y no una tarea?
• ¿Todos los mensajes de commit explican el cambio, y no se
  limitan a repetir el nombre del fichero que se ha cambiado?
• ¿Los mensajes de commit siguen el formato estándar y buenas prácticas?
• ¿Se ha hecho una revisión real del código para comprobar que todos
  los atributos y funciones creadas están respaldadas por una HU?
• ¿Todos los issues creados están asignados a una HU?
• ¿Todos los cambios en el código están asignados a un issue al que se
  referencia en un commit? Los issues sobre los que estoy trabajando, ¿han
  sido asignados al primer milestone?
• ¿Se ha asignado al mismo milestone el PR que se ha hecho?
• ¿Son los milestones sobre los que estoy trabajando productos
  mínimamente viables? ¿O tengo que solicitar al product manager que
  cree milestones adicionales o precise de qué producto se trata?
• ¿Se ha comprobado que el código entregado sea sintácticamente
  correcto?

[PabloSpiegel]

No apruebo ahora mismo por ver si te parece hacer este pequeño cambio de nombre. Por el resto de cosas me parece una buena documentación del proceso para llegar al código y un buen analísis :)

[PabloSpiegel]

@JJ listo para revisión

[JJ]

Por favor, sigue las mejores prácticas en los mensajes de commit.

[JJ]

Como te he comentado, el análisis y modelización del problema no queda nada claro aquí. Como hicimos en el hackatón, a través de diferentes issues tienes que llegar hasta el objeto valor más simple que se pueda representar; a partir de él ir construyendo el resto de los objetos/valor y entidades.
Recuerda que lo esencial aquí no es poner nombre a las variables, sino tener un modelo claro del problema.

[JJ]

iv.yaml es un conjunto de claves-valor. Por lo tanto hay que poner sólo una clave. Consulta como se representan arrays en YAML.

[JJ]

No tratéis de representar como atributos absolutamente todo. Prediccion para empezar, no corresponde a este milestone. Pero lo importante es que se trataría del resultado de una función.

[danielsp13]

¡Hola @RafaelT00! Supongo que ya habrás visto la corrección realizada por @JJ. Puedes mencionarme si necesitas ayuda o revise los cambios que hagas. 👊