Objetivo 2 [IV-22-23]

[JoseCarlosPPK]

Sobre la estructura del repositorio

• [x] ¿He seguido las mejores prácticas en nombre de las clases y ficheros y disposición de los mismos?
• El nombre de los ficheros están en minúscula para evitar problemas con otros SOs y filesystems que no distinguen entre mayúculas y minúsculas. En JS se usa camelCase (variables, funciones), PascalCase para clases y todo en mayúsculas para constantes

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?

• En el cuerpo de los issues se habla del análisis realizado.

• [x] ¿Se ha documentado por qué se ha elegido que lo creado sea un objeto valor, una entidad o un agregado? Lo respondo aquí mismo. El modelo se basa en:

  1. Los objeto-valor Libro y ConjuntoGeneros. Estos son inmutables. Cuando se crea un objeto libro sus propiedades no pueden modificarse y lo mismo pasa cuando creas un objeto de ConjuntoGeneros.
  2. La entidad Usuario. Es una entidad porque sus gustos pueden variar.

• [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)?. Creo que sí he propuesto un PMV. Los gustos del usuario se basan en los géneros de los libros y de esta manera se pueden realizar comparaciones para poder luego recomendar libros. El objeto-valor ConjuntoGeneros no depende de ningún otro y es la base del objeto-valor Libro y la entidad Usuario

Sobre la planificación y la programación

• [x] ¿Los issues representan un problema, y no una tarea?
• [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?
• Mayoritariamente sí. La primera línea es <= a 50 caracteres. Se indica un verbo en imperativo que indica la acción realizado. Se ha escrito un cuerpo del commit que describa con más detalle el cambio realizado.
• [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 asignados a una HU?
• [ ] ¿Todos los cambios en el código están asignados a un issue al que se referencia en un commit?
• Hay algunos que no referencian al issue. Esto es debido a que era un cambio de nombre, añadir comentarios al código... y no sabía cómo asociarlo o no me parecía correcto. He asociado un commit a un issue cuando se añadía/modificaba código.
• [x] Los issues sobre los que estoy trabajando, ¿han sido asignados al primer milestone?
• [x] ¿Se ha asignado al mismo milestone el PR que se ha hecho?
• [x] ¿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?
• [x] ¿Se ha comprobado que el código entregado sea sintácticamente correcto? Con node --check se puede comprobar la sintaxis y no hay ningún problema.

Close #9 porque está mal planteado y no se va a seguir con su desarrollo. Close #11 porque no se va a seguir con su desarrollo.

[JoseCarlosPPK]

En estos dos últimos commits la he liado un poco. El commit d6a3b8b lo quería subir sin una entrada para entidad en el fichero iv.yaml y subí un fichero desactualizado

[pedrooot]

Como ha comentado @JJ, los libros tienen más atributos de los que estás creando en libro.js (título...). Tampoco me queda muy claro el tema de la puntuación ya que esta se asigna dependiendo de los gustos de cada usuario y la implementación actual de la misma toma la puntuación como algo general sin tener en cuenta el usuario (Para cada libro, la puntuación del mismo es distinta dependiendo de los gustos del usuario).
Intenta ir revisando estas cosas y vamos viendo 😬

[JoseCarlosPPK]

Listo para revisión @fjgallardo00 !

[JoseCarlosPPK]

Perdón por cerrar el PR, ha sido sin querer. Me he confundido con cancelar el comentario que iba a escribir

[JoseCarlosPPK]

El resumen de los cambios:

1. Los géneros se han modelado como una clase que como atributo de clase tiene el conjunto de géneros global y cada instancia será un subconjunto de este.
2. Se han modelado los usuarios. Cada usuario encapsula sus gustos, que son objetos de la clase ConjuntoGeneros.
3. Se ha eliminado la clase que relacionaba la puntuación con los libros. Como bien dijo @pedromarting3 , el modelo anterior representaba una puntuación global para todos los usuarios para un mismo libro. Una vez modelados los usuarios, para solucionar el problema comentado por @pedromarting3, en vez de tener la pareja (libro, puntuación) se podría tener la terna (usuario, libro, puntuación), pero la idea de esta clase era ayudar a la lógica de negocio cuando tuviera que ordenar los libros con mayores puntuaciones. Es aquí cuando no me queda claro si esta clase debería formar parte del modelo y por eso la he quitado, pensando que es algo más interno de la lógica de negocio

[JoseCarlosPPK]

Con esto estaría listo para revisión @fjgallardo00

[fjgallardo00]

@JoseCarlosJC el archivo de iv.yaml le falta un retorno de carro. No te pasarán los tests de JJ si no se lo pones. Por lo demás lo veo todo bien

[JoseCarlosPPK]

Le he añadido esa nueva línea al final aunque no se muestra aquí una tercera línea

[JoseCarlosPPK]

Listo para revisión @JJ . No puedo volver a pasar los tests porque me aprobó el PR y no debería abrir otro para el mismo objetivo según las normas

[JoseCarlosPPK]

Listo para revisión @fjgallardo00 @JJ! He quitado el setter y el código de asginación al atributo solo lo ejecuta el constructor. Además como mejora (pienso), ningún objeto de la clase puede modificar el atributo de clase GENEROS. Para los libros he quitado el atributo descripcion que no se menciona en ningún issue y no es necesario para el PMV.

El issue #12 he reformulado el título para que exprese un problema, no sé si el error estaba ahí, en la expresión. El problema es que se han de modelar los libros porque la lógica de negocio los usa para sus cálculos y finalmente como recomendaciones (esto está expresado en el issue)

[JJ]

Listo para revisión @fjgallardo00 @JJ! He quitado el setter y el código de asginación al atributo solo lo ejecuta el constructor. Además como mejora (pienso), ningún objeto de la clase puede modificar el atributo de clase GENEROS. Para los libros he quitado el atributo descripcion que no se menciona en ningún issue y no es necesario para el PMV.

El issue #12 he reformulado el título para que exprese un problema, no sé si el error estaba ahí, en la expresión. El problema es que se han de modelar los libros porque la lógica de negocio los usa para sus cálculos y finalmente como recomendaciones (esto está expresado en el issue)

Repetidamente os he dicho que reformular un issue es una mala práctica. La buena práctica es cerrarlo cuando se borra el código que se ha creado con él y crear un nuevo issue.

[JoseCarlosPPK]

Listo para revisión @fjgallardo00 @JJ! He quitado el setter y el código de asginación al atributo solo lo ejecuta el constructor. Además como mejora (pienso), ningún objeto de la clase puede modificar el atributo de clase GENEROS. Para los libros he quitado el atributo descripcion que no se menciona en ningún issue y no es necesario para el PMV. El issue #12 he reformulado el título para que exprese un problema, no sé si el error estaba ahí, en la expresión. El problema es que se han de modelar los libros porque la lógica de negocio los usa para sus cálculos y finalmente como recomendaciones (esto está expresado en el issue)

Repetidamente os he dicho que reformular un issue es una mala práctica. La buena práctica es cerrarlo cuando se borra el código que se ha creado con él y crear un nuevo issue.

Pues tengo un problema. Si tuviera que crear otro issue sería muy parecido al que ya está. Pensaba que el error estaba en cómo había formulado o expresado el issue (el título). Me gustaría saber el porqué no representa un problema el issue #12

[JJ]

No he dicho que no represente un problema. He dicho que reescribir un issue es una mala práctica. Hay que cerrarlo, borrar el código y hacer uno nuevo.

[JoseCarlosPPK]

Otra pregunta @JJ es si tengo que tener un issue general, que represente al objetivo por así decirlo para añadir el fichero iv.yaml . O tal vez para este no haga falta

[JJ]

TL;DR: siempre que se aporte código al repositorio, hay que hacerlo siguiendo un issue.

Otra pregunta @JJ es si tengo que tener un issue general, que represente al objetivo por así decirlo para añadir el fichero iv.yaml . O tal vez para este no haga falta

Esa no es la pregunta. La pregunta es si el issue plantea un problema. Los issues siempre tienen que plantear un problema.

También la pregunta es "si pongo esto así te quedarás satisfecho". No, no me quedaré satisfecho. Los issues se crean no porque a mi me guste o me haya dado por ahí, y no se plantean como un problema para echar para atrás todo lo que no me parezca un problema. Se plantean porque la ingeniería es resolver problemas (dicho el primer día de clase) y la única forma de saber si realmente se ha resuelto un problema es plantear un issue, escribir código para resolverlo, y escribir un test que compruebe que efectivamente el código resuelve el problema.

Por otro lado, la pregunta es "si hago esto así, si estará bien o no". Y esto también os lo respondí el primer día. La asignatura, y la ingeniería en general, te tiene que decir dos cosas: qué tengo que hacer ahora, y si lo que hago está bien. Para lo primero, está la progresión de los objetivos; para lo segundo, la asignatura tiene las revisiones de código. Así que hasta que no escribas issue, escribas el código correspondiente, y hagas el test (o en este objetivo aprobación por @fjgallardo00 y por mi parte) o se revise, no sabré si está bien o no.

Entiendo que queráis optimizar vuestro tiempo y no hacer cosas que están mal. Pero debéis de entender que para no hacer cosas que están mal tenéis que haber seguido las directrices y metodologías que están en clase, y la metodología de dar clase implica que si no son correctas o no contribuyen al objetivo, se revisan y se solicita que se cambien. Para optimizar mi tiempo, desde luego, lo más adecuado sería que intentárais hacer las cosas tras mirar los errores frecuentes y las explicaciones que se han hecho en clase, en este caso sobre el concepto de issue. Pero es legítimo que hagáis lo que veáis y yo tenga que revisarlo; aparte, es mi obligación hacerlo y es como aporto valor a vuestro trabajo.