[IV-23-24] Objetivo 2

[spmanolo]

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?

[spmanolo]

@DarckMonster He creado la nueva estructura, cuando puedas échale un vistazo y asigna el M0 al PR y al nuevo issue :)

[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]

@DarckMonster Cuando puedas le echas un vistazo y me dices :smile: @danieeeld2 Gracias otra vez!!

[danieeeld2]

@DarckMonster Cuando puedas le echas un vistazo y me dices 😄 @danieeeld2 Gracias otra vez!!

Si necesitas cualquier cosilla etiquetame sin probelmas😄

[spmanolo]

@DarckMonster si necesitas que te aclare algo me dices :)

[DarckMonster]

@DarckMonster si necesitas que te aclare algo me dices :)

Nada, en cuanto a código lo veo bien :).

[spmanolo]

Perfe pues revisalo cuando puedas porfa para poder mencionar a JJ :)

[DarckMonster]

Perfe pues revisalo cuando puedas porfa para poder mencionar a JJ :)

Ya aprobé los cambios hace 4 días :D.

[spmanolo]

@JJ Listo para revisión :smile:

[JJ]

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

Algunos issues como el #16 no están asignados a ninguna historia de usuario.

* [x]  ¿Los issues representan un problema, y no una tarea?

Issues como #16 simplemente prescriben qué es lo que hay que hacer sin siquiera plantear el problema correspondiente.

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?

No hay ninguna evidencia de que así sea.

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

Me temo que no es así.

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

En algunos casos no se menciona ningún issue.

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

No se ha hecho o no hay evidencia de que sea así.

[JJ]

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

Me temo que no es así, como he comentado en el anterior. Que se plantee de esa forma es simplemente un método para que el código que se vaya creando sea efectivamente un valor para el cliente y se pueda usar en objetivos posteriores. Si no se hace así, os podéis encontrar con que tenéis que realizar todo el trabajo de nuevo en el objetivo 4, resultando en un retraso en vuestro propio trabajo. Tomar en serio esta lista de comprobación es lo mejor no sólo para vosotros dos, sino evidentemente para mi, que puedo usar el tiempo para sugerir mejoras a otro nivel.

[spmanolo]

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

Algunos issues como el #16 no están asignados a ninguna historia de usuario.

* [x]  ¿Los issues representan un problema, y no una tarea?

Issues como #16 simplemente prescriben qué es lo que hay que hacer sin siquiera plantear el problema correspondiente.

Es verdad que en #16 se me olvidó mencionar la HU con la que se está trabajando, pero creo que se describe bien el problema: puede haber incompatibilidades entre distintas monedas y se debería unificar en una sola moneda.

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?

No hay ninguna evidencia de que así sea.

En cuanto a la documentación, creo que en cada issue está bien descrito el problema y la estructura que se ha creado para solucionarlo.

[spmanolo]

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?

Me temo que no es así.

Creo que en todos los commits se comentan los cambios o añadidos si no en el título, en la descripción, referenciando los issues con los que se está trabajando en el caso que sea necesario y no se limitan a decir que se la modificado X fichero.

[JJ]

En cuanto a la documentación, creo que en cada issue está bien descrito el problema y la estructura que se ha creado para solucionarlo.

No es así, como ya he indicado en los issues correspondientes, pero es que los issues son simplemente una exposición de los difererntes problemas, mientras que la solución se debe comentar en los mensajes de commit.

[JJ]

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?

Me temo que no es así.

Creo que en todos los commits se comentan los cambios o añadidos si no en el título, en la descripción, referenciando los issues con los que se está trabajando en el caso que sea necesario y no se limitan a decir que se la modificado X fichero.

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?

Me temo que no es así.

Creo que en todos los commits se comentan los cambios o añadidos si no en el título, en la descripción, referenciando los issues con los que se está trabajando en el caso que sea necesario y no se limitan a decir que se la modificado X fichero.

No se hace en el indicado y en dos más. En el caso de los dos primeros podría justificarse, pero en todo caso, contradecir la revisión hecha, ¿de qué forma crees que contribuye a que alcances el objetivo?

[spmanolo]

En cuanto a la documentación, creo que en cada issue está bien descrito el problema y la estructura que se ha creado para solucionarlo.

No es así, como ya he indicado en los issues correspondientes, pero es que los issues son simplemente una exposición de los difererntes problemas, mientras que la solución se debe comentar en los mensajes de commit.

Vale lo tendré en cuenta para los próximos. Gracias.

[spmanolo]

No se hace en el indicado y en dos más. En el caso de los dos primeros podría justificarse, pero en todo caso, contradecir la revisión hecha, ¿de qué forma crees que contribuye a que alcances el objetivo?

No pretendo contradecir la revisión, solo que no me ha quedado claro qué problema hay en 177fc0cbdb98f64b8950d8099505e598619f92c8, mi pregunta es si es una modificación interna del código que resuelve un problema interno, ¿haría falta abrir un issue? y en el caso de abrirlo, ¿tendría ninguna correlación con alguna HU?, ya que el problema es solo eliminar comentarios en el código. Me gustaría que me explicara con un poco más de detalle los errores. Gracias.

[spmanolo]

Ya he hecho los comentarios en los issues correspondientes. Si los issues son inválidos, lo mejor es empezar desde cero, cerrandolos todos desde un commit (o el cuerpo del PR) marcándolos como inválidos y comenzar desde cero. También deberíais tener en cuenta el planteamiento. En proyectos de procesamiento de la información, lo principal es tener una estructura de datos que permita procesar esa información, buscando la presencia de datos específicos y redireccionando a funciones específicas. Os recuerdo que las funciones pueden ser también datos (ser almacenadas en una variable, por ejemplo). Si sólo trabajáis con los productos de salida de la lógica de negocio, la modelización del problema es bastante escasa. Siempre hay que hacer un ejercicio, por las dos partes, de simulación de la programación de la lógica de negocio, empezando por los datos de entrada, mirando si existe toda la información precisa para procesarlo, y eventualmente con los datos de salida. Si no se hace esa simulación se corre el riesgo de dejar grandes huecos que tendrán que ser cubiertos por la persona que programa el proyecto en el objetivo 4

Y en cuanto al planteamiento, tampoco me ha quedado claro qué es lo que está mal, si pudiera ser un poco más específico se lo agradecería. Si tengo que empezar de cero otra vez lo hago, pero me gustaría saber primero como puedo plantear mejor la estructura y qué es lo que le falta. Gracias.

[JJ]

No se hace en el indicado y en dos más. En el caso de los dos primeros podría justificarse, pero en todo caso, contradecir la revisión hecha, ¿de qué forma crees que contribuye a que alcances el objetivo?

No pretendo contradecir la revisión, solo que no me ha quedado claro qué problema hay en 177fc0c, mi pregunta es si es una modificación interna del código que resuelve un problema interno, ¿haría falta abrir un issue? y en el caso de abrirlo, ¿tendría ninguna correlación con alguna HU?, ya que el problema es solo eliminar comentarios en el código. Me gustaría que me explicara con un poco más de detalle los errores. Gracias.

No, no hace falta abrir un issue, pero cuando se hace una solicitud de revisión de código es porque según el revisor parece que o no corresponde a una solución del problema planteado o ni siquiera está planteado el problema; en eso consisten las revisiones. Recuerda que hay dos preguntas en ingeniería: qué hago ahora, si lo que hago está bien. En esta fase no tenemos ninguna forma automática para afirmar lo que está bien o no. Quien revisa (@DarckMonster y yo) miran las historias de usuario, miran los issues que se han creado a partir de ellos (los problemas planteados) y a partir de ahí sugieren cambios sobre aspectos específicos. Los cambios deben de ir en la dirección de ajustarse mejor a la HU o explicar mejor de qué forma son una solución. Por eso, la mejor práctica en este caso es hacer lo mismo: mirar la HU y el issue, y cambiar la solución para que siga más fielmente el issue... Y por eso hay que enlazar el issue en el mensaje de commit.

En general, la orientación al cliente del desarrollo ágil implica en la práctica que hay que justificar todo código como enfocado a aportar valor al cliente, no al revisor del PR. Por eso hacer un commit que responda solamente a una revisión, y ponerlo así, no suele ser correcto (en general y en este contexto; puede haber casos específicos en los que se comente alguna regla general de la empresa, en cuyo caso el issue a enlazar es el propio PR. Cuando el código esté en la rama principal, la única forma que tienes de entender qué soluciona y por qué está ahí es mirar qué enlaza, que es donde tienes todo el contexto)

[JJ]

Ya he hecho los comentarios en los issues correspondientes. Si los issues son inválidos, lo mejor es empezar desde cero, cerrandolos todos desde un commit (o el cuerpo del PR) marcándolos como inválidos y comenzar desde cero. También deberíais tener en cuenta el planteamiento. En proyectos de procesamiento de la información, lo principal es tener una estructura de datos que permita procesar esa información, buscando la presencia de datos específicos y redireccionando a funciones específicas. Os recuerdo que las funciones pueden ser también datos (ser almacenadas en una variable, por ejemplo). Si sólo trabajáis con los productos de salida de la lógica de negocio, la modelización del problema es bastante escasa. Siempre hay que hacer un ejercicio, por las dos partes, de simulación de la programación de la lógica de negocio, empezando por los datos de entrada, mirando si existe toda la información precisa para procesarlo, y eventualmente con los datos de salida. Si no se hace esa simulación se corre el riesgo de dejar grandes huecos que tendrán que ser cubiertos por la persona que programa el proyecto en el objetivo 4

Y en cuanto al planteamiento, tampoco me ha quedado claro qué es lo que está mal, si pudiera ser un poco más específico se lo agradecería. Si tengo que empezar de cero otra vez lo hago, pero me gustaría saber primero como puedo plantear mejor la estructura y qué es lo que le falta. Gracias.

Lo que le falta, en general, es que los issues tienen 1. que representar un problema y 2. que enlazar la HU y plantear un problema implícito en la misma. Eres tú el que tienes que estructurar los issues teniendo en cuenta estas dos cosas. Te he ofrecido la posibilidad de que cuando crees los issues (y el primer código) pidas revisión, para ver si los issues está bien o no, o simplemente que lo veamos en clase. Pero lo que se busca en este objetivo es que sepáis plantear issues como problemas, porque eso es lo que se va a hacer de ahora en adelante en prácticamente todos los objetivos. Y para ello, claro, tenéis que aprender a plantear problemas y a saber qué es un problema y qué no, y a mi me toca evaluarlo.

[spmanolo]

No se hace en el indicado y en dos más. En el caso de los dos primeros podría justificarse, pero en todo caso, contradecir la revisión hecha, ¿de qué forma crees que contribuye a que alcances el objetivo?

No pretendo contradecir la revisión, solo que no me ha quedado claro qué problema hay en 177fc0c, mi pregunta es si es una modificación interna del código que resuelve un problema interno, ¿haría falta abrir un issue? y en el caso de abrirlo, ¿tendría ninguna correlación con alguna HU?, ya que el problema es solo eliminar comentarios en el código. Me gustaría que me explicara con un poco más de detalle los errores. Gracias.

No, no hace falta abrir un issue, pero cuando se hace una solicitud de revisión de código es porque según el revisor parece que o no corresponde a una solución del problema planteado o ni siquiera está planteado el problema; en eso consisten las revisiones. Recuerda que hay dos preguntas en ingeniería: qué hago ahora, si lo que hago está bien. En esta fase no tenemos ninguna forma automática para afirmar lo que está bien o no. Quien revisa (@DarckMonster y yo) miran las historias de usuario, miran los issues que se han creado a partir de ellos (los problemas planteados) y a partir de ahí sugieren cambios sobre aspectos específicos. Los cambios deben de ir en la dirección de ajustarse mejor a la HU o explicar mejor de qué forma son una solución. Por eso, la mejor práctica en este caso es hacer lo mismo: mirar la HU y el issue, y cambiar la solución para que siga más fielmente el issue... Y por eso hay que enlazar el issue en el mensaje de commit.

En general, la orientación al cliente del desarrollo ágil implica en la práctica que hay que justificar todo código como enfocado a aportar valor al cliente, no al revisor del PR. Por eso hacer un commit que responda solamente a una revisión, y ponerlo así, no suele ser correcto (en general y en este contexto; puede haber casos específicos en los que se comente alguna regla general de la empresa, en cuyo caso el issue a enlazar es el propio PR. Cuando el código esté en la rama principal, la única forma que tienes de entender qué soluciona y por qué está ahí es mirar qué enlaza, que es donde tienes todo el contexto)

Entonces si yo hago un cambio repondiendo a una revisión como debería hacer el commit, ¿enlazando el PR?

[JJ]

Entonces si yo hago un cambio repondiendo a una revisión como debería hacer el commit, ¿enlazando el PR?

Como te digo, todos los cambios deben añadir valor al cliente. Si es un cambio puramente "administrativo" (error ortográfico en un nombre de variable, quitar algo del .gitignore) la relación del cliente es muy tenua, por lo que se puede enlazar o el PR o directamente el comentario (que tienen URL único). Pero si es un cambio relativo a la solución de un problema en un issue (que esté enlazado con un PR) evidentemente hay que enlazar dicho issue.

[spmanolo]

Vale gracias. Voy a volver a empezar, borro todo y dejo el fichero iv.yaml para que @DarckMonster pueda hacer merge, seguir trabajando en el siguiente objetivo y no seguir atrasándolo, perdón otra vez :face_exhaling:

[spmanolo]

Listo para hacer merge @DarckMonster :+1: