David Alba Ajete y Jose Carlos Pendas

[d4v3x7d1]

Modifique las líneas siguientes con los detalles relevantes:

Equipo

• C211, Lazaro David Alba Ajete (@davidalba2001)
• C211, Jose Carlos Pendas Rodriguez (@P3ND4)

Proyecto

• Repositorio: https://github.com/davidalba2001/Second_Project_Dominoes
• Proyecto: https://github.com/davidalba2001/Second_Project_Dominoes/blob/main/README.md

Checklist

(Esta lista es para el mentor. Hasta que no estén chequeados estos elementos no se procederá a la evaluación en persona.)

Básicos

• El repositorio indicado existe y tiene un Readme.md no vacío.
• Los miembros del equipo tienen un usuario de Github válido.
• El proyecto puede ser ejecutado siguiendo las instrucciones del Readme.md.
• El reporte existe y tiene la longitud adecuada.

Funcionalidades

• El proyecto permite configurar al menos 5 elementos relevantes de la mecánica del dominó.
• El proyecto contiene 2 implementaciones diferentes de cada elemento configurable.
• El proyecto permite personalizar las estrategias de los jugadores virtuales.
• El proyecto contiene al menos 3 implementaciones diferentes de jugadores virtuales.

Ingeniería de Software

• Las estrategias de jugadores virtuales pueden combinarse con cualquier configuración del juego de forma transparente.
• La interfaz gráfica permite configurar el juego en toda la extensión que brinda la lógica.
• Las jerarquías de clases y demás abstracciones existentes son adecuadas para modelar el dominio.
• El código muestra una organización y estructura mantenible y extensible, respetando las buenas prácticas de la ingeniería de software.

Documentación

• El reporte técnico explica de forma suficientemente detallada los pormenores del proyecto.
• Los nombres de clases, métodos y variables son descriptivos.
• Los comentarios son legibles y útiles para entender el funcionamiento del código.

Revisión

Fecha prevista: 2020/XX/XX

Comentarios

El reporte existe y tiene la longitud adecuada.
El reporte técnico explica de forma suficientemente detallada los pormenores del proyecto.

No hay reporte en la raíz del proyecto 😱

Los comentarios son legibles y útiles para entender el funcionamiento del código.

Hay muy pocos comentarios en el código (casi ninguno) y no ayudan mucho a entender el mismo.

[jmederosalvarado]

La idea del informe es explicar la arquitectura del proyecto de forma tal que quien lo lea entienda, a un alto nivel, como funciona todo, como encajan las diferentes piezas. Para esto es posible que sea necesario en algun momento mostrar un fragmento de codigo para poder hacer entender mejor una idea, pero no es el objetivo del informe que simplemente aparezca el codigo de todas las clases con unos comentarios de que hace cada una, para esto es el codigo y los comentarios, no el informe.

[jmederosalvarado]

A nivel de ingeniería de software me llama la atencion que para algunas funcionalidades no se crearon las abstracciones correctas y el codigo por ende no queda lo suficientemente desacoplado. Por ejemplo, el human strategy dentro del engine del domino, utiliza Console para preguntar cosas al usuario en la consola y hacer la jugada; esto limita mucho la flexibilidad del engine e indica en general un mal diseño, el engine no deberia saber que esta corriendo en un ConsoleApplication, lo que es mas, deberia permitir reutilizar el mismo engine en diferentes tipos de apps visuales, a la vez q dependes de imprimir en una consola ya esto no es posible. Una posible solucion para este problema es que el human strategy se inicialice con algo que le permita hacer preguntas al usuario de forma generica, por ejemplo algo como una interface con metodos del estilo AskNextPlay. Cada tipo de app visual inicializaria este strategy con una implementacion diferente de como interactuar con el usuario en estos metodos.

[jmederosalvarado]

Me llama la atencion tambien que en la app visual no estan las cosas encapsuladas y desacopladas suficientemente. Se hace mucho uso de switch case con mucho codigo dentro de cada case para poner a andar el juego, este tipo de patrones generalmente se resuelven poniendo las dferentes fases de inicializacion en clases, y luego invocando estos objetos initializers para que inicializen el estado del juego. Esto es con el objetivo de que la app visual tambien sea extensible y mantenible a largo plazo.