beerjs / jaen

Jaén, España
18 stars 0 forks source link

Sobre la idea de trabajar en un pequeño proyecto para afianzar lo de TDD #3

Open vrivas opened 8 years ago

vrivas commented 8 years ago

Como comentó @lynx, podemos hacer un pequeño proyecto para afianzar conceptos; como por ejemplo los relacionados con test-driven development. A mi juicio el proyecto debería ser muy, muy simple, para pelearnos con los conceptos, no con el problema en si. Por ejemplo, propongo hacer una página web en la que el usuario deba adivinar un número al azar entre 0 y 100. Para practicar con lo que nos enseñó @spawnsito, deberíamos usar:

La forma de trabajar podría ser la siguiente:

Por supuesto tendría que estar hecho antes de la próxima reunión que, posiblemente, será el 21 de enero, por lo que estuvimos hablando.

Ah, y se puede invitar a participar a todo el mundo que deseemos; incluso podemos inventarnos algún premio, pero habrá que estar presente en la próxima reunión para acceder a él.

Ea, a responder toca :smile:

dmoyadev commented 8 years ago

Yo he empezado a tocar Gulp a raíz de lo que se explicó. Por ahora he entendido cómo funciona y creo que lo estoy tratando medio bien. El tema de la página web para averiguar un número del 0 al 100 me parece adecuado ya que no es complicado al fin y al cabo, y para tocar estos temas es muy adecuado.

amalbala commented 8 years ago

Buenas, por aportar.

Aunque no he ido a ninguna de las dos quedadas de BeerJS (y como sean los jueves, la cosa va a estar complicada)

Me gustaría compartir con vosotros algunas ideas sobre TDD. Desconozco cual es vuestro nivel de TDD, pero si el objetivo es empezar a probar o intentar entender el ciclo Red - Green - Refactoring, creo que el proyecto de la web para adivinar números aleatorios es excesivamente compleja.

Cuando se empieza con TDD, el cambio es importante y las primeras dudas empiezan en el minuto 0, ¿por donde empiezo? ¿el html hay que testarlo? ¿y las librerías? ¿lo que carga bower?, etc.

Para empezar con TDD, lo mejor son las katas, por varios motivos:

Para JS a nivel introductorio yo optaría por:

Enteded que cuando se habla de JavaScript no se habla necesariamente de Web, y además que en cuanto hayas montado cualquier entorno cliente-servidor con TDD, tiene que tener toda la pirámide de tests:

  1. Aceptación
  2. Integración
  3. Unitarios

Además hay dos enfoques de TDD (Según GOOS) inside-out y outside - in. Que dependen un poco del nivel de TDD que tengáis,

Me daría mucha rabia que por ser muy ambiciosos al principio abandonáseis un flujo de programación que tiene muchas ventajas y que en realidad es un proceso de diseño y construcción de software robusto, pero que a priori exige bastante esfuerzo y cambio de mentalidad. Intentar hace un proyecto en el que aprender TDD, nuevos frameworks, gestión de dependencias, librerías de terceros, todo a la vez corre el riesgo de no aprender nada.

Saludos

cruzcivieta commented 8 years ago

Buenas a todos.

No pude contestar antes porque estuve liado.

Comparto totalmente la idea de Antonio. Yo os hablé un poco por encima (no profundicé nada, la charla iba sobre gulp) de eso porque es lo que estoy estudiando ahora mismo pero no deberíais ir tan rápido. Hay una base teórica y mucha práctica detrás de todo eso. Para empezar se debería de empezar por algo más simple y como dice Antonio sin framework ni nada.

Yo creo que se debería reflexionar hacia donde se quiere llevar la comunidad (sólo a cosas referentes al lenguaje como gulp, bower... o también relacionadas con metodologías de desarrollo) y dar pasos más chicos. A lo mejor una buena charla sería patrones de diseño aplicados en javascript (por decir algo).

Ya sabéis el que mucho abarca poco aprieta.

Saludos!

El 17 de diciembre de 2015, 18:11, amalbala notifications@github.com escribió:

Buenas, por aportar.

Aunque no he ido a ninguna de las dos quedadas de BeerJS (y como sean los jueves, la cosa va a estar complicada)

Me gustaría compartir con vosotros algunas ideas sobre TDD. Desconozco cual es vuestro nivel de TDD, pero si el objetivo es empezar a probar o intentar entender el ciclo Red - Green - Refactoring, creo que el proyecto de la web para adivinar números aleatorios es excesivamente compleja.

Cuando se empieza con TDD, el cambio es importante y las primeras dudas empiezan en el minuto 0, ¿por donde empiezo? ¿el html hay que testarlo? ¿y las librerías? ¿lo que carga bower?, etc.

Para empezar con TDD, lo mejor son las katas, por varios motivos:

  • El problema nunca es el objetivo es el proceso.
  • Tienen 0 dependencias (no hay librerías ni frameworks)
  • Permite acometer problemas de diseño y de arqutectura.

Para JS a nivel introductorio yo optaría por:

Enteded que cuando se habla de JavaScript no se habla necesariamente de Web, y además que en cuanto hayas montado cualquier entorno cliente-servidor con TDD, tiene que tener toda la pirámide de tests:

  1. Aceptación
  2. Integración
  3. Unitarios

Además hay dos enfoques de TDD (Según GOOS) inside-out y outside - in. Que dependen un poco del nivel de TDD que tengáis,

Me daría mucha rabia que por ser muy ambiciosos al principio abandonáseis un flujo de programación que tiene muchas ventajas y que en realidad es un proceso de diseño y construcción de software robusto, pero que a priori exige bastante esfuerzo y cambio de mentalidad. Intentar hace un proyecto en el que aprender TDD, nuevos frameworks, gestión de dependencias, librerías de terceros, todo a la vez corre el riesgo de no aprender nada.

Saludos

— Reply to this email directly or view it on GitHub https://github.com/beerjs/jaen/issues/3#issuecomment-165517453.

Daniel Cruz CivietaIngeniero Informático

https://twitter.com/dcruzing https://www.linkedin.com/profile/view?id=186634640

vrivas commented 8 years ago

Hola. Gracias a ambos por las sugerencias. En realidad, y en respuesta a @spawnsito, podemos llevar esta pequeña comunidad a donde queramos; donde a cada uno más le interese... donde nos interese a todos... en serio, donde queramos. De hecho, no tiene que ser una sola cosa. Podemos abrir muchos frentes y avanzar poco a poco por cada uno de ellos. Pero también podemos intentar convertirnos en expertos en algo concreto; o, por el contrario, podemos optar simplemente por conocer qué es lo que existe y luego que cada uno utilice lo que más le convenga. Con solo dos reuniones ya están saliendo un montón de conceptos: TDD; katas, Scalar (.js), patrones de diseño... Si os parece, olvidamos por ahora lo del pequeño proyecto TDD para la próxima reunión. Me miro lo de las katas y lo expongo el 24. Además, que @joseja8 nos cuente lo que había preparado de Scalar (creo que era él, ¿no?) y si alguien se anima, que se prepare algún patrón de diseño.