UTNianos

(29-03-2012 23:44)Aivan escribió: [ -> ]

(29-03-2012 15:56)el pibe escribió: [ -> ]Pero si en vez de diseñar, programas; que comparacion vas a hacer ?


A ver si nos entendemos

Primero diseñas, despues programas basado en ese diseño.

Si programas directamente.... donde esta el diseño ?

Mmmmmmm nono..... A ver.... Esa concepción no tiene mucho sentido de aplicación... Vos primero ante todo esbozas un buen diseño y a partir del mismo haces un startup y comenzas el desarrollo. Los vas modificando "on the fly" para adaptarse a tus necesidades y refinandolo de a poco. Hay gran dinamismo en el mercado hoy en día, los requerimientos no suelen ser muy estables (de ahí la necesidad de metodologías tipo Scrum y XP) y constantemente tenes que ir cambiando, por lo que no conviene diseñar primero y programar después, conviene crear una base estable y construir y modificar de ahí para adelante. Hoy en día te encontras con herramientas onda TDD (ya más adelante vas a verlo) que desde la programación (los tests específicamente) vas encontrando el diseño de tu sistema y puliendolo cada vez más. Sugiero que se lo preguntes al profe y fijate que te dice... Vas a ver que es necesario...

Saludos

(30-03-2012 01:52)el pibe escribió: [ -> ]es fija que los requerimientos cambian facilmente.

pero la posta es tener un diseño solido que sea adaptable.

Si programas directamente, cuando tengas que modificar algo, lo mas probable es que tengas que "hacer borron y cuenta nueva".

Cita:En cuanto al TDD, todos aprendemos a programar asi, solo que lo llamamos "a prueba y error"

(30-03-2012 12:38)Aivan escribió: [ -> ]Es necesario programar algo en Diseño, ya que es lo que te vas a encontrar en el mercado laboral hoy en día. En cuanto a TDD, es una demostración de lo que te digo .

Cita:En cuanto al TDD, todos aprendemos a programar asi, solo que lo llamamos "a prueba y error"

Cita:Si te mandas a programar a prueba y error, y ni siquiera tenes una base de que tenes que hacer, podes estar dias intentado tirar 4 lineas de codigo

Cita:Si programas directamente, cuando tengas que modificar algo, lo mas probable es que tengas que "hacer borron y cuenta nueva".

Off-topic:

TDD se basa en la idea de dar pequeños pasos. Vos tenes tu diseño en la cabeza, pero no codeaste los metodos de cada objeto. Armas un test para un caso de uso con un input puntual, falla, codeas el metodo para que cumpla con eso, funciona. Entonces refactoreas para que cumpla con el siguiente input y asi vas de lo particular a lo general. Y asi vas haciendo con todos los casos de uso. Vas de casos hipersencillos a casos mucho mas complejos.

Y cuando digo hacer tests, el limite lo podes vos como programador. No hablo de clickear a mano botones. Hablo de unit tests, de tests de servicios, tests de controllers, tests de integracion, y hasta si queres algo de BDD (con cucumber o specflow). Lo bueno que trae todo esto es que a la hora de poner a prueba tu diseño y hacerle alguna modificacion, tenes un monton de tests automatizados que te permiten validar si rompiste otra cosa o no.

Esto es muy distinto a prueba y error

(30-03-2012 12:59)el pibe escribió: [ -> ]

(30-03-2012 12:38)Aivan escribió: [ -> ]Es necesario programar algo en Diseño, ya que es lo que te vas a encontrar en el mercado laboral hoy en día. En cuanto a TDD, es una demostración de lo que te digo .

No, ni ahi. Tenes que tener una base, llamala "diseño"

Si te mandas a programar a prueba y error, y ni siquiera tenes una base de que tenes que hacer, podes estar dias intentado tirar 4 lineas de codigo

(30-03-2012 10:34)NykolaZ escribió: [ -> ]Año 2012:

Martes mañana: Iriarte / Passerini.
Martes tarde: Passerini.
Miércoles noche: Dodino / xxxx.


Subir más data no está de más, para los que se quieran cambiar.

(31-03-2012 22:39)nanuiit escribió: [ -> ]

(30-03-2012 10:34)NykolaZ escribió: [ -> ]Año 2012:

Martes mañana: Iriarte / Passerini.
Martes tarde: Passerini.
Miércoles noche: Dodino / xxxx.


Subir más data no está de más, para los que se quieran cambiar.

Viernes Noche: Leone