[IV-24-25] Objetivo 4 #23
Conversation
Se decide emplear el estándar de golang
Se emplea el estándar de golang
|
Buenas he revisado tu PR y he dejado un par de comentarios para que puedas mejorarlo. Mucho ánimo |
…mantenimiento y corrige redacción #20
Se eliminan números mágicos, comentarios innecesarios, constructor y otras funciones innecesarias
Deshacemos cambios en el código para reestructurarlos y que se muestren adecuadamente en los issues
Este test comprueba que no haya más de un enfermero asignado al mismo área al mismo tiempo en el plan generado
Comprueba que no falte nadie en un área en cualquier momento
Comprueba que la información sobre sus turnos se muestra correctamente
Crea el planning de turnos para todo un año dados los enfermeros contratados
Convierte los turnos asignados a un enfermero en string y lo devuelve
He intentado volver a dar pasos sobre el código para documentar los cambios en los cambios realizados. Adicionalmente, he creado sus issues correspondientes, espero que sean suficientes. Si tienes alguna recomendación es bienvenida. Muchas gracias! |
Gracias por tu colaboración Juan. He reorganizado un poco la estructura de los tests y cambiado los issues. Espero tú revisión, |
internal/turnos-asignados.go
Outdated
| fechaActual := time.Now() | ||
|
|
||
| for i := 0; i < diasAnio; i++ { | ||
| fecha := fechaActual.AddDate(0, 0, i) |
There was a problem hiding this comment.
¿Esto no crea todas las fechas con la hora en el momento que se crea el Plan Anual? No sé yo como de correcto es que alguien del turno de noche tenga que su fecha es el 05 de febrero a las 15:37. A no ser que el atributo hora del tipo de dato sea irrelevante, en ese caso igual sería mejor usar otro tipo de dato, ¿no crees? Algo como un struct con un dia, un mes y un año (puedes usar time.Month y time.Year) y crear tu propio AddDate y no tendrías que cambiar apenas el código que ya tienes hecho.
There was a problem hiding this comment.
Y aquí sí que voy a parar. Tenéis que hacer modificaciones como respuesta a todos los comentarios. Cerrar un comentario sin ningún tipo de comentario ni modificación es una falta de respeto a la persona que lo ha hecho y ha invertido su tiempo en ello.
Un año puede durar 365 o 366 días por lo que es incorrecto llamar a la constante de esa manera
Tienes razón, lo acabo de modificar. |
There was a problem hiding this comment.
El que todo lo que se pide en la asignatura sea útil para desarrollar y aportar valor al cliente puedes creértelo o no, eso ya es cosa de cada uno. Si no te lo crees puedes superar un objetivo, dos objetivos o tres, quizás con un poco de suerte o con algún despiste mío. No vas a llegar mucho más allá, sin embargo. Porque según vas avanzando en los objetivos, todo lo que ves son "tonterías que hay que hacer para escribir código que es lo que de verdad importa".
Y no, no importa el código. El código lo pude escribir una IA. Lo que no puede hacer una IA es plantearse problemas, sopesar diferentes opciones para resolverlos, y finalmente generare el código que las resuelva de una forma mínima y satisfactoria. Eso no lo puede hacer.
Os rogaría que tratárais de aprender lo que no es capaz de hacer el código, porque eso es lo que os va a dar trabajo. No crear un issue que diga "hay que crear una fecha" y decirle a ChatGPT "hazme una fecha" y generar un total de unas 150 líneas de código que tengo yo que revisar y que, cualquier cosa que haga para revisarlas, no te va a aportar ningún valor porque seguirán siendo "las tonterías que hay que hacer para escribir código"
Hay dos formas para solucionar esto. Cambias esta línea o la otra, y nos metemos en un bucle donde vamos viendo en 10 o 12 iteraciones una forma de reconducir esto por un camino en el que se pueda pasar el objetivo. Es posible que para esas fechas sea mayo de 2026, pero se llegará.
Hay otra forma. Cambiar de actitud. Tratar de entender lo que se pide y por qué. Y ver que realmente, por ese camino, es más fácil avanzar y llegar a la meta antes del 7 de febrero. Puedes hacer lo que quieras, es decisión tuya, y cualquier decisión será legítima. Cuando lo hagas, pídeme revisión de nuevo, por favor.
La modificación del modelo ha sido un error y no debería haber abordado el tema de la fecha de esa manera, no aporta valor a la lógica del milestone 1 ni forma parte del pmv
Nos deshacemos de ella porque no forma parte del pmv
Para obtener el plan deberemos generarlo a través de los datos que se nos ofrezca por lo que se creará la función en base a los tests siguiendo TDD
Este test comprueba si hay áreas sin ocupar y las notifica, en lo que será un error
Este test comprueba si hay más de una persona asignada a un área al mismo tiempo, que indica sobreocupación, y lo notifica
Aplicamos el principio DRY para evitar repetición de código creando el dato Ocupación que guarda el número de enfermeros en cada área en cada momento
Tras completar los tests a tener en cuenta, completamos la función de creación del plan siguiendo el TDD
Se establecen las bases para considerar correcta la solución a aplicar para que los enfermeros comprueben sus turnos
Se crea la función que muestra al enfermero el área al que debe acudir
Al incluir una hora indeterminada usando time.Now() las igualdades entre fechas eran erróneas, se opta por crear una función que normalice las fechas dejando la hora en 0
|
@JJ revisión. |
En informática siempre hay varias maneras de hacer las cosas. Si dices que algo es "imprescindible" es que simplemente no has explorado otras maneras. |
There was a problem hiding this comment.
De veras que lo siento, pero no voy a seguir revisando en esta vuelta después de los comentarios que te he hecho en diferentes issues. No parece que estés llevando a cabo la metodología que se enuncia en el guión.
- Estás creando issues que no representan problemas, y esto después de lo comentado. Si todo lo que entendéis cuando hago una revisión detallada en la que invierto una buena cantidad de tiempo es "voy a hacer otra vez lo mismo para que tenga que volver a invertir la misma cantidad de tiempo", no sé si merece la pena hacerlo. Después de decirte que no había que crear issues que dijeran "hay que crear una fecha" sigue habiendo uno que dice "como crear un plan" que fue creado antes de eso, pero sobre el cual sigue habiendo código presente, código que sigue siendo inevaluable.
- Lo que has hecho es cerrar ese issue como completado. No está completado, simplemente es incorrecto. Pero si es incorrecto, todo el código que se ha creado lo es, y la forma correcta de hacerlo es borrar ese código, indicando en el issue donde se hace "closes #xxx", y comenzar de nuevo, con issues nuevos Si no al final tenemos una serie de parches que sólo hacen todo más difícil de evaluar.
Voy a seguir corrigiendo en todo caso por si pudiera añadirte algún valor, pero si no se sigue una metodología correcta desde el principio es imposible que se haga así.
internal/turnos-asignados.go
Outdated
| fechaActual := time.Now() | ||
|
|
||
| for i := 0; i < diasAnio; i++ { | ||
| fecha := fechaActual.AddDate(0, 0, i) |
There was a problem hiding this comment.
Y aquí sí que voy a parar. Tenéis que hacer modificaciones como respuesta a todos los comentarios. Cerrar un comentario sin ningún tipo de comentario ni modificación es una falta de respeto a la persona que lo ha hecho y ha invertido su tiempo en ello.
…issue #39 Para determinar como correcta la solución al issue, un empleado debe poder comprobar el área al que asistir dados su nombre y la fecha y el turno en el que asiste
No hay necesidad en un principio de cambiar la fecha, por lo que se devuelve a su estado original y se cambia el nombre por uno más entendible
|
@JJ revisión. |
El issue no define un problema por lo que el código creado para el mismo está mal
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?
Sí, estoy leyendo
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?
Fast: son tests rápidos (unos 2 milisegundos)
Independent: ninguno depende de otra función testeada
Repeatable: los datos usados son invariables, da el mismo resultado cada vez
Self-validating: aserciones claras que muestran cuando falla, en caso contrario el test se pasa correctamente
Timely: los tests son oportunos ya que estamos siguiendo TDD y es a partir de ellos que generamos la lógica de negocio correcta.
considere viable?