[IV-23-23] Objetivo 4 #29
Conversation
DarckMonster
modified the milestones:
[M0] Modelo del problema,
[M1] Algoritmo de web sraping
There was a problem hiding this comment.
Sobre los issues, al menos para mí (y creo que en general es cómo se debe hacer) me es mucho más fácil crear issues específicos para cada problema que vaya surgiendo, en vez de explicar todo lo que vas a hacer en un issue solo. Así es mucho más fácil de entender los commits también, pues sabes que van directos a resolver ese problema en concreto. De la otra forma no se sabe muy bien qué parte del issue va a resolver cada commit.
Además de que hay unos cuantos commits que no siguen las mejores prácticas. Recuerda que cada commit debe ir dirigido a resolver un issue, y que no está de más si incluyes una descripción en el cuerpo del commit explicando qué has solventado.
Sí, tienes razón, me di cuenta en cuanto iba haciendo commits. Planee que los commits iban a ir sobre las tres cosas... |
There was a problem hiding this comment.
No lo he revisado completo, pero lo de usar caminos absolutos bloquea la superación del objetivo. Por favor, dale una vuelta (y el resto de los detalles, por favor) Y muchas gracias a @adelahera por la revisión.
There was a problem hiding this comment.
Creo que has hecho un esfuerzo bastante completo en la documentación y en el código, pero el problema es que este último resulta algo complejo de entender para quien lo revisa, y por lo tanto complicado saber si satisface o no la historia de usuario. Por favor, dale una pequeña vuelta empezando por los issues y reescribe las partes de código que creas que están afectadas.
|
... y cuando termines pide revisión |
There was a problem hiding this comment.
Te rogaría que revisaras, una vez más, todos los comentarios, pero sobre todo que no resuelvas comentarios que no están, en realidad, resueltos. En la mayoría de los casos, cuando se hace un comentario específico sobre un código o texto específico, es para que ese texto se altere o directamente se suprima, si lo que se cuestiona es su necesidad. Mantener el texto y cerrar el comentario sólo lleva a más trabajo por las dos partes, pero especialmente la mía. ¿Crees que es la mejor forma de invertir nuestro tiempo, pero sobre todo el tuyo?
Por otro lado, convendría que miraras los errores frecuentes. Mira especialmente esto:
Usar "flags" para decidir si una cosa se ha encontrado o no. Los bucles se tienen que tratar de evitar siempre que haya alternativas, y la forma correcta de encontrar algo es filtrar un array que devuelva los que cumplen el criterior, o uno vacío si no hay ninguno. Trabajar con índices y bucles es herencia de tiempos pasados en los que los lenguajes no tenían órdenes de más alto nivel para trabajar con ellos.
También:
Hay que tratar de consultar cuál es la buena práctica actual para las estructuras de un lenguaje, en todos los sentidos. Por ejemplo:
Cómo declarar las variables de instancia en TypeScript
Qué tipo de convención usar cuando se trata de variables privadas de clase.
Cómo declarar los getters y setters en JS/TS.
(en tu caso, qué son las clases sin funciones)
En general, dale también una vuelta al resto de los errores frecuentes, y trata de evitarlos en la próxima revisión. Ánimo, que ya queda menos.
… solo lectura, modificable en un txt
usuario que desarrolla, pasando por el mensaje de commit y el issue
correspondiente?
esté desarrollando?
este objetivo?
módulos o paquetes más fundamentales frente a otros, movidos a otro
PMV/Hito?
delante?
de test runner?
test runners lo son realmente y tienen la misma funcionalidad? ¿O estás poniendo
unittestcomo test runner ypytestcomo biblioteca de aserciones?búsqueda para las diferentes opciones?
se ha documentado cómo se ha hecho?
considere viable?