JJ / IV

Asignatura de infraestructuras virtuales para el Grado de Informática
https://jj.github.io/IV
72 stars 83 forks source link

Prestar atención al diseño de la clase en el objetivo 2 #191

Open JJ opened 2 years ago

JJ commented 2 years ago

Dar a entender que las responsabilidades de cada clase, cómo avanzan los objetivos, y lo demás, debe de preceder a crear el código de la clase. Explicar también que las clases no se diseñan de forma aislada, sino que se tienen que pensar en el diseño de cada una en conjunto

(Interpretación libre de los comentarios de @Balrrach)

Balrrach commented 2 years ago

Explicar también que las clases no se diseñan de forma aislada, sino que se tienen que pensar en el diseño de cada una por separado

Se tiene que pensar el diseño de cada una en conjunto. Creo que es un error de escritura.

Quizás sería interesante romper el segundo objetivo en dos pequeños objetivos. Un primero(obligatoria en parejas) en el que se trata de estructurar el repositorio en términos de historias de usuario e issues y en el que se realiza el diseño de las diferentes clases y un segundo(que puede ser individual para agilizar el proceso) en el que se implementa esta estructura. La ventaja de hacerlo de esta forma es que el proceso de diseño es inherentemente creativo y la colaboración es muy positiva y natural, además, los compañeros con más confianza con herramientas cómo git o github y, sobre todo, con el desarrollo ágil pueden ayudar a los menos experimentados a estructurar el repositorio mientras se realiza una taréa útil; el diseño de las diferentes clases. Además, separarlo en dos objetivos, el primero en pareja y el segundo individual, permite establecer una barrera clara entre diseño y la implementación de forma que no queda duda que en desarrollo ágil, aunque la implementación puede quedar a cargo de un equipo relativamente aislado del resto, el diseño es una puesta común y se ha de mantener una coherencia y sentido con el resto del proyetcto.

JJ commented 2 years ago

Explicar también que las clases no se diseñan de forma aislada, sino que se tienen que pensar en el diseño de cada una por separado

Se tiene que pensar el diseño de cada una en conjunto. Creo que es un error de escritura.

Cierto. Corregido.

Quizás sería interesante romper el segundo objetivo en dos pequeños objetivos. Un primero(obligatoria en parejas) en el que se trata de estructurar el repositorio en términos de historias de usuario e issues y en el que se realiza el diseño de las diferentes clases y un segundo(que puede ser individual para agilizar el proceso) en el que se implementa esta estructura. La ventaja de hacerlo de esta forma es que el proceso de diseño es inherentemente creativo y la colaboración es muy positiva y natural, además, los compañeros con más confianza con herramientas cómo git o github y, sobre todo, con el desarrollo ágil pueden ayudar a los menos experimentados a estructurar el repositorio mientras se realiza una taréa útil; el diseño de las diferentes clases. Además, separarlo en dos objetivos, el primero en pareja y el segundo individual, permite establecer una barrera clara entre diseño y la implementación de forma que no queda duda que en desarrollo ágil, aunque la implementación puede quedar a cargo de un equipo relativamente aislado del resto, el diseño es una puesta común y se ha de mantener una coherencia y sentido con el resto del proyetcto.

OK, lo pensaré así. Muchas gracias.