FabriConde commented 1 month ago

Lista de comprobación para quien desarrolle el objetivo

Sobre la estructura del repositorio

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

[x] ¿He mirado tanto reglas generales (para cualquier repo) como reglas específicas para el lenguaje con el que se está trabajando? Sobre el planteamiento

[x] ¿Se han planteado una serie de issues, asignados a las historias de usuario pertinentes, que clarifiquen qué es lo que necesitan los usuarios e identifiquen las diferentes partes del problema?

[x] ¿Los issues representan un problema, y no una tarea? Sobre el análisis del problema

[x] ¿Se ha documentado qué análisis se ha hecho sobre el dominio para decir lo que se ha creado?

[x] ¿Se ha documentado por qué se ha elegido que lo creado sea un objeto valor, una entidad o un agregado?

[x] ¿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 el código

[x] ¿Todos los mensajes de commit explican el cambio, y no se limitan a repetir el nombre del fichero que se ha cambiado?

[x] ¿Los mensajes de commit siguen el formato estándar y buenas prácticas?

[x] ¿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?

[x] ¿Todos los issues creados están relacionados con a una HU?

[x] ¿Ha asignado el propietario/la propietaria del repositorio todos los issues planteados al milestone correspondiente?

[x] ¿Todos los cambios en el código están asignados a un issue al que se referencia en un commit?

[x] ¿Se ha asignado al mismo milestone el PR que se ha hecho?

[x] ¿Es el milestone sobre el que estoy trabajando un producto mínimamente viable? ¿O tengo que solicitar al product manager que precise de qué producto se trata?

[x] ¿Se ha comprobado que el código entregado sea sintácticamente correcto?

Lista de comprobación para el propietario/a del repositorio

[x] ¿Los issues que ha planteado la persona son efectivamente problemas y evidencian comprensión de las historias de usuario? Si no es así, es mejor que se le transmita antes de que empiece a crear cualquier código erróneo.
[x] ¿Has comprobado que efectivamente el compañero/a ha seguido su lista de comprobación?
[x] ¿El código creado es una modelización válida de las historias de usuario creadas por ti, y te sirve como base para programar la lógica de negocio?
[x] ¿El código creado sigue las mejores prácticas para el lenguaje de programación que hayáis consensuado, tanto en identificadores, como nombres de ficheros, como disposición de los diferentes ficheros en el repositorio? Por ejemplo, ¿todos los commits se refieren a un issue y aportan código para resolver el problema planteado en el mismo?
[x] ¿He comprobado que el código compile, o que quien lo ha programado ha lo ha hecho y documentado en el repositorio?
[x] ¿He añadido el PR y todos los issues que se resuelvan en él al milestone correspondiente, que será el primero?
[x] ¿Cubre totalmente el milestone 0, o hará falta modelización adicional en el objetivo 4 para poder programar la lógica de negocio?
[x] En resumen, ¿considero que con lo hecho puedo ponerme a trabajar directamente en el siguiente milestone, que incluye la lógica de negocio?

FabriConde commented 1 month ago

@juanbarearojo Cuando puedas revisa todo y cualquier cambio me dices.

juanbarearojo commented 4 weeks ago

Veo un gran esfuerzo realizado por tu parte. Sin embargo hay ciertos aspectos que considero que no se ha seguido la metodología.

juanbarearojo commented 4 weeks ago

Veo que tanto como en receta inventario ingrediente y semana se ha seguido de forma correcta la metodología.

juanbarearojo commented 4 weeks ago

Los issues #8 #7 #14 no son necesario ya que deberían de resolverse al cerrar el #6. En este caso en el commit 6a681bf0849e27ee4be49a0c8d1be2b284b1f0f7 no es necesario poner el main.go ya que en este caso no tiene historias de usuario asociadas y por ende no aporta valor al cliente. Aun así aprecio bastante mucho tu esfuerzo realizado

FabriConde commented 4 weeks ago

Los issues #8 #7 #14 no son necesario ya que deberían de resolverse al cerrar el #6. En este caso en el commit 6a681bf no es necesario poner el main.go ya que en este caso no tiene historias de usuario asociadas y por ende no aporta valor al cliente. Aun así aprecio bastante mucho tu esfuerzo realizado

Gracias por la palabras. Si, hay cosas que cambiar, mañana en clase lo hablamos.

FabriConde commented 3 weeks ago

@juanbarearojo Cuando puedas aprueba el cambio que he hecho, que me ha saltado un test por tener un archivo con mayúsculas.

FabriConde commented 2 weeks ago

Revisión @JJ

FabriConde commented 2 weeks ago

@JJ Revisión

FabriConde commented 1 week ago

@JJ Revisión

JJ commented 1 week ago

Si no atendéis a los comentarios que os hacen, y hacéis más, o menos, es muy complicado llegar a una solución aceptable.

FabriConde commented 1 week ago

Si no atendéis a los comentarios que os hacen, y hacéis más, o menos, es muy complicado llegar a una solución aceptable.

Si, eliminé los constructores porque supuse que también había que borralos porque no eran un PMV y no hice caso a mi compañero. Corregido @juanbarearojo

juanbarearojo commented 1 week ago

Ahora lo veo bastante mejor veo. Gracias por corregirlo

FabriConde commented 1 week ago

@JJ Revisión

JJ commented 1 week ago

Ahora lo veo bastante mejor veo. Gracias por corregirlo

Por favor, ¿os cuesta mucho trabajo aprobarlo explícitamente? No tenéis más que mirar en el botón "Review" y marcar en "Approve"

FabriConde commented 1 week ago

@juanbarearojo Corregido.

FabriConde commented 3 days ago

@JJ Revisión

FabriConde commented 3 days ago

@juanbarearojo He creado una nueva estructura llamada Producto junto con su issue #22 que contiene nombre y tipoIngrediente para que sea un objeto valor inmutable que asegura que los valores sean únicos y no cambien. Ahora Ingrediente es una entidad y tiene: producto, cantidad y fechaCaducidad y la he añadido al iv.yaml. He eliminado la comprobación de la fecha de caducidad porque hay alimentos perecederos que tiene y que no tienen fecha de caducidad, así que solo lo he dejado como opcional. Si ves bien lo de la nueva estructura Producto (#22) falta que se le asigne el M0. Cuando puedas le echas un vistazo y lo corriges, gracias.

juanbarearojo commented 2 days ago

@FabriConde ya está asignado

FabriConde commented 2 days ago

@JJ Revisión

FabriConde commented 1 day ago

Si la hu solo menciona si son perecederos o no. Solo será necesario poner eso para llegar al PVM

Voy a dejar el tipo de ingrediente en Producto como opcional y que el tipo de ingrediente por el momento solo sea Perecedero. ¿Te parece bien?

JJ commented 1 day ago

Si la hu solo menciona si son perecederos o no. Solo será necesario poner eso para llegar al PVM

Voy a dejar el tipo de ingrediente en Producto como opcional y que el tipo de ingrediente por el momento solo sea Perecedero. ¿Te parece bien?

Solo intervenir para repetirte que la forma que tiene tanto @juanbarearojo o yo de decir si una cosa está bien o no es mirar el código, ver si está bien desarrollado y corresponde a la HU y milestone, y aprobarlo o comentarlo o pedir cambios.

FabriConde commented 1 day ago

@juanbarearojo cuando puedas mira los cambios

FabriConde commented 12 hours ago

@JJ Lista para revisar

FabriConde commented 11 hours ago

@JJ Ahora si que está listo para revisar

juanbarearojo / privateChef

[IV-24-25] Objetivo 2 #15

Lista de comprobación para quien desarrolle el objetivo

Lista de comprobación para el propietario/a del repositorio