[IV-23-24] Objetivo 2

[spmanolo]

Lista de comprobación

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?

[DarckMonster]

Hola, encantado de trabajar contigo, te asigno el M0. :smile:

[spmanolo]

Hola @DarckMonster, he modificado un poco la estructura comentada en #10 después de darle unas vueltas. Acabo de crear la nueva estructura, cuando puedas échale un vistazo y me comentas :smile:

[DarckMonster]

Hola @DarckMonster, he modificado un poco la estructura comentada en #10 después de darle unas vueltas. Acabo de crear la nueva estructura, cuando puedas échale un vistazo y me comentas 😄

Tras revisar el código has hecho un buen trabajo, ahora te comento sobre el código. :ok_hand:

[spmanolo]

Hola @DarckMonster, he modificado un poco la estructura comentada en #10 después de darle unas vueltas. Acabo de crear la nueva estructura, cuando puedas échale un vistazo y me comentas 😄

Tras revisar el código has hecho un buen trabajo, ahora te comento sobre el código. 👌

Hola! Cuando puedas revisame el código para poder mencionar al profesor y que lo termine de revisar. Y también asigna los issues al milestone 0. Gracias! :smile:

[DarckMonster]

Hola @DarckMonster, he modificado un poco la estructura comentada en #10 después de darle unas vueltas. Acabo de crear la nueva estructura, cuando puedas échale un vistazo y me comentas 😄

Tras revisar el código has hecho un buen trabajo, ahora te comento sobre el código. 👌

Hola! Cuando puedas revisame el código para poder mencionar al profesor y que lo termine de revisar. Y también asigna los issues al milestone 0. Gracias! 😄

Si, ya te asigné al M0 los issues. Ya te escribí sobre el código mencionandolo aqui en el PR.

[spmanolo]

Perfecto, gracias! @JJ listo para revisión.

[spmanolo]

@DarckMonster Por cierto no olvides poner cuando puedas aquí tu lista de comprobación, la del propietario del repo.

[JJ]

Sí, por favor, aprobad explícitamente y en el mensaje de aprobación seguid la lista de comprobación.

[spmanolo]

Vale, @DarckMonster cuando puedas apruebame el código porfa :)

[DarckMonster]

Vale, @DarckMonster cuando puedas apruebame el código porfa :)

No ves una review de una linea de código?

[spmanolo]

Vale, @DarckMonster cuando puedas apruebame el código porfa :)

No ves una review de una linea de código?

No la veo

[spmanolo]

@DarckMonster Creo que tienes que confirmar los cambios en el botón de Review Changes

[DarckMonster]

@spmanolo disculpa por el fallo! 😞

[spmanolo]

@spmanolo disculpa por el fallo! 😞

No te preocupes :)

[DarckMonster]

• [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?

[spmanolo]

Gracias! 😄 @JJ Listo para revisión.

[spmanolo]

@JJ He modificado el nombre de los ficheros para ajustarme a las buenas prácticas.

[JJ]

La mayoría de los commits "añadido x" no se ajustan a las buenas prácticas, como se indica en los errores frecuentes.

Poner en el mensaje de commit "Solución xx". Decir que es la solución no contribuye a entender por qué se trata de la solución. Tampoco "Añadido x". El mensaje debe añadir información a lo que ya es evidente, porque en la información del mismo se ve claramente qué se ha añadido o modificado. Debe explicar por qué se ha tomado esa decisión específica de crear ese objeto para resolver el problema y no otro.

Los mensajes de commit no se pueden modificar, pero no seguir las buenas prácticas en este aspecto generalmente es indicación de que no se han seguido en otros casos y que por tanto hará falta otra ronda de revisión. Te agradeceré que conozcas las buenas prácticas y las sigas en ese caso (y en el futuro en tu repo)

[spmanolo]

Debido a todos los errores, voy a cerrar este PR y comenzar de nuevo con los issues y la propuesta. @DarckMonster perdón si tardo un poco en hacer esto.

[JJ]

Lo mejor sería que dejaras solo el iv.yaml y fusionaras esto cerrando el ticket del lenguaje. Cuando crees la rama ya tienes eso hecho, y si @DarckMonster quiere seguir al objetivo siguiente puede sacar una rama directamente de lo fusionado.