Buscar la tarjeta gráfica más barata.

[DarckMonster]

Para cumplir con la historia de usuario #4 tenemos que encontrar los componentes más baratos. El usuario podrá ver los precios de los procesadores para comparar y los precios de tarjetas gráficas dento de un modelo. Dado que las CPUs tienen un único manufacturador, no hay posible comparación entre en mismo modelo, solo se pueden comparar modelos distintos, por lo que no existe un modelo más barato.

Lo importante es las tarjetas gráficas que tienen distintos manufacturadores por modelo y ahí podemos buscar cuál es la más barata.

[JJ]

Con este issue es muy complicado saber qué problema estás planteando, o si lo estás planteando con la atomicidad suficiente para poder trabajar. No dices dónde se encuentra el precio, cómo se encuentra codificado, cómo hay que extraerlo... Por favor, repásalo y mira a ver si, en caso de que no supieras nada del tema, serías capaz de escribir el código que has escrito. Eso hace también que crees commits muy grandes como este, donde es muy difícil ver la correspondencia entre este issue y, por ejemplo, los tipos de tarjetas que pones (y el que uses un ENUM para ellos, lo que restringiría el tipo de componentes que se puede usar siempre). Por favor, trata de reconsiderar los issues para algo que sea más inmediatamente convertible en código o va a ser muy complicado que lo que lleves a cabo pueda convertirse en código que cumpla #4

[DarckMonster]

En este issue creo la lógica de negocio referida a encontrar la gpu más barata. En el desarrollo de esta función vi que venía muy bien introducir modelos. Pero cuando tenía la función de encontrar la más barata casi hecha introducí los modelos.

En un commit añadí los modelos y en el siguiente terminé la funcioón de gpu más barata. En el desarrollo de esta, hice pequeños cambios en todo el código para adaptarla y otros cambios como escribir de otra forma la manera de abrir arhivos usando bibliotecas de bun.

[JJ]

Los issues no "crean", plantean problemas. Los modelos tienen que ser también modelo de un problema, que también tiene que estar en un issue. Si no está planteado el problema claramente en el issue es muy difícil o imposible evaluar si el código resuelve el problema correctamente, me temo.

[JJ]

Fíjate por ejemplo que el commit mencionado dice "encontrar la GPU más barata", cuando la GPU ni siquiera la mencionas en este issue. Para garantizar la calidad de los issues y el código correspondiente deben plantear claramente el problema, para que la persona que los evalúe entienda lo que se está haciendo (y la propia persona que lo hace en un futuro próximo)

[DarckMonster]

En este issue me refiero varias veces a que se va a buscar la tarjeta gráfica más barata (o GPU).

[JJ]

En este issue me refiero varias veces a que se va a buscar la tarjeta gráfica más barata (o GPU).

Me vas a perdonar, Juan, pero no dices eso. Dices:

El usuario podrá ver los precios de los procesadores para comparar y los precios de tarjetas gráficas por producto

No haces ninguna referencia a tipo de procesador, ni siquiera a si incluyes "GPU" en "procesador" o en "tarjeta gráfica". Está claro que tú entiendes lo que estás haciendo, pero en un issue es esencial que todas las personas involucradas en el desarrollo entiendan los diferentes aspectos de un problema; es más, que haya issues que formulen los diferentes aspectos de un problema: de qué tipo de componentes estamos hablando, por ejemplo.

Es más, en #4 se habla de "páginas web" y aquí lo que estás usando para testear son ficheros de texto. El principal problema de la lógica de negocio es efectivamente extraer el contenido de las páginas web con HTML. Si crees que un producto mínimamente viable es pasar las páginas web a texto con algún programa sencillo y vas a trabajar sobre ese problema, en principio me vale, siempre que tengas muy claro que eso no es el problema enunciado desde el principio. Pero por favor, trata de entender que la metodología de este objeto es la que hace que se pueda desarrollar de forma más eficiente en un equipo. Si alguna de las partes de la metodología falla (los issues, los mensajes de commit) es muy complicado que el resultado deje satisfecho al cliente, como sucede en desarrollo ágil.

[DarckMonster]

En cuanto a la primera parte, lo que digo en esa linea es que con lo que ya está hecho se pueden ver todos los CPUs (ya implementado) y los precios de GPU por producto(debería haber puesto modelo, lo voy a editar) (ya implementado).

tipo de procesador, ni siquiera a si incluyes "GPU" en "procesador" o en "tarjeta gráfica".

La verdad, no entendí esta parte, pero espero que le aclare con el párrafo anterior.

En cuanto a extraer la página web deirectamente veo que sin sofware adicional no puedo sacar de pccomponentes el html. Así que tuve que descargarla manualmente. Me encantaría poder hacerlo y si usted sabe como estaría encantado de hacerlo ya que estoy haciendo un proyecto no solo para la asignatura, sino también para mi.

En cuanto a la metodología de desarrollo ágil es cierto que no la he consguido usar de forma correcta, me falta atomicidad en los commits y en los issues. Si quiere puedo reescribir los issues en más divisiones de los que tengo y hacer un commit para resetear el código y volver a hacer commit de forma correcta.

[JJ]

Creo que sería conveniente que los diferentes problemas que has encontrado, y has ido resolviendo, los especificaras en issues, replanteándote si la solución es adecuada o no. Eso te ayudará a evolucionar el código y hacerlo más genérico.

[DarckMonster]

Correcto.