Objetivo 2 - Githubissues

marcosrmartin commented 1 year ago

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? 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?
[x] ¿Se ha documentado por qué se ha elegido que lo creado sea un objeto valor, una entidad o un agregado? En los commits.
[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 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?
[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? Si. ¿Han sido asignados al primer milestone? No, ya que los hemos rehecho.
[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?

Hola Daniel, estas son las estructuras de datos que he pensado que pueden resolver el problema con algunas comprobaciones de errores, si ves que se pueden añadir más lo hablamos. Aparte de esto, la entidad Ruta he decidido que almacene una puntuación para la heurística, un tramo nuevo y un puntero a otro objeto Ruta, ya que así la estructura se podría usar recursivamente (para algoritmos como Dijkstra, y otros de VRP). Si ves que hay algo mal dímelo, y le doy otra vuelta, en el caso de ser sobre la ED Ruta, abrimos un issue para discutirlo allí, de lo contrario espero la aprobación.🤝

dmonjasm commented 1 year ago

He estado revisando el código y está todo bien, menos en la implementación de Ruta, que creo que el atributo tramo debería ser una slice o un list ya que entiendo que una ruta tendrá varios tramos y no solo uno. Por otro lado falta añadir la inicialización del modulo (el go.mod) en el directorio raíz. Cambiado eso yo lo veo ya todo bien.

marcosrmartin commented 1 year ago

Lo que he hecho es que una Ruta pueda tener otra Ruta dentro, y como cada Ruta tiene un tramo, ese seria la "list" de tramos, ya que se podría recorrer recursivamente.

dmonjasm commented 1 year ago

vale ya veo lo que dices, pues entonces lo veo todo bien. Le doy el ok

marcosrmartin commented 1 year ago

@JJ Listo para revisión.

Carlos-SE commented 1 year ago

@marcosrmartin, creo que deberías cambiar los issues o crear unos nuevos ya que los que has planteado han sido titulados como si fuesen historias de usuario. También añadir que en los issues no tienes que proponer la solución, tienes que plantear el problema y avanzar sobre ellos con los commits adecuados.

JJ commented 1 year ago

He estado revisando el código y está todo bien, menos en la implementación de Ruta, que creo que el atributo tramo debería ser una slice o un list ya que entiendo que una ruta tendrá varios tramos y no solo uno. Por otro lado falta añadir la inicialización del modulo (el go.mod) en el directorio raíz. Cambiado eso yo lo veo ya todo bien.

Esto debes hacerlo inline en el código correspondiente. Por favor, aprended a hacer estas cosas.

JJ commented 1 year ago

@marcosrmartin, creo que deberías cambiar los issues o crear unos nuevos ya que los que has planteado han sido titulados como si fuesen historias de usuario. También añadir que en los issues no tienes que proponer la solución, tienes que plantear el problema y avanzar sobre ellos con los commits adecuados.

Esencialmente es esto mismo. Hay issues que están marcados como historias de usuario pero no lo son, no están relacionados con ninguna historia de usuario, y no plantean problemas. El que (más o menos) plantea uno, el #12 (que tampoco es una historia de usuario) sólo tiene un puñado de commits.

Por favor, seguid también las prácticas habituales en commits "Avanza #xx" no es lo adecuado.

JJ commented 1 year ago

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?

No estoy seguro de que internal sea lo más habitual. He visto pkg, por ejemplo, pero no esto.

  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?

Si no lo has hecho, no lo marques.

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

Tampoco.

dmonjasm commented 1 year ago

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?
No estoy seguro de que internal sea lo más habitual. He visto pkg, por ejemplo, pero no esto.

Buscando las buenas prácticas de GO vi que un proyecto GO básico suele tener tres directorios cmd, pkg e internal. En este caso solo se ha creado internal porque es el directorio que contiene el código privado del proyecto. Adjunto enlace ProjectStruture

JJ commented 1 year ago

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?
No estoy seguro de que internal sea lo más habitual. He visto pkg, por ejemplo, pero no esto.
Buscando las buenas prácticas de GO vi que un proyecto GO básico suele tener tres directorios cmd, pkg e internal. En este caso solo se ha creado internal porque es el directorio que contiene el código privado del proyecto. Adjunto enlace ProjectStruture

¿Por qué es privado y no externo? ¿Cómo has modelado el código para decidir eso?

dmonjasm commented 1 year ago

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?
No estoy seguro de que internal sea lo más habitual. He visto pkg, por ejemplo, pero no esto.
Buscando las buenas prácticas de GO vi que un proyecto GO básico suele tener tres directorios cmd, pkg e internal. En este caso solo se ha creado internal porque es el directorio que contiene el código privado del proyecto. Adjunto enlace ProjectStruture
¿Por qué es privado y no externo? ¿Cómo has modelado el código para decidir eso?

Entiendo que el modelado de las entidades y objetos valor de este proyecto son útiles sólo para este proyecto, luego por eso se mete en internal. Tenía entendido que en pkg se mete aquel código que puede ser útil para otro proyecto o servicios.

Carlos-SE commented 1 year ago

Buenas, @marcosrmartin. Los issues ya tienen mejor pinta, sigue así y mucho ánimo! 👍

marcosrmartin commented 1 year ago

@JJ Listo para revisión.

marcosrmartin commented 1 year ago

@JJ Listo para revisión.

dmonjasm / RouteCheck

Objetivo 2 #17