Guillermo Obregon
Jul 18, 2014, 2:05:46 PM7/18/14
to comun...@googlegroups.com
Esto lo lei en otra lista y me parecio interesante, alguno habia escuchado esta forma de implementar TDD?
http://en.wikipedia.org/wiki/Test-driven_development
Copio lo leido:
"Como en TDD, se trata de hacer los unit test primero y luego la implementación. El giro se trata en que los test y la implementación no la hacen la misma persona. Es decir, cada dev hace los unit test de una funcionalidad que luego otro dev implementa y viceversa. En una primer googleada encontré esto: http://programmers.stackexchange.com/a/102509 . No logré encontrar por ahora referencias a un proceso más formal.
Me pareció intesante porque promueve - revisión temprana de código, - integración de equipos, - peer development, - conocimiento compartido de funcionalidades del sistema, y - mejora las condiciones de contigencia en caso de bajas y ramp up (seguramente haya otras relacionadas con integración de equipos)
Seguramente haya cuestiones como planteos entre devs que no están de acuerdo con los test que hizo otro, pero creo que justamente son cosas que sucederían de cualquier forma y este approach hace que se identifiquen en forma temprana."
Es la primera vez que lo escucho. Si alguien lo ha adoptado, me gustaría conocer los resultados.
Saludos
Guillermo
@el_guiye
Dardo Valdez
Jul 18, 2014, 5:59:21 PM7/18/14
to comun...@googlegroups.com
Opinando sin experiencia práctica en TDD (bah, algo), creo que podrías probar la técnica modificada en cierto contexto y compararla con la técnica original en un contexto similar. Más o menos es como se va viendo si la modificación resulta para mejor en el contexto total de desarrollo en el que se quiere aplicar ( developers, sus skillsets, las ganas que le ponen, la comodidad de cómo están laburando ahora vs. el cambio a realizar, si hay lugar físico para sentarse al lado del compañero que va a ser tu par en la técnica, cuando haga falta conversar algo, y 150 etc. más)
La metodología original TDD parece muy buena a primera vista, sin embargo, cuando se la embebe a entornos de desarrollo complejos, empieza a crear "problemas emergentes" rápidamente que hay que gestionar, y eso se refleja en comentarios y artículos por la red, a veces se los puede gestionar y a veces el trabajo de "gestión" extra desamerita usar TDD.
En mis pruebas hace unos años atrás, TDD se llevaba muy bien para escribir scripts complejos (python, ruby), sin embargo, tenía la sensación de que usar TDD al hacer desarrollo de aplicaciones "power", TDD podría llegar a crear más problemas que entregar resultados.
Por lo que leí en su momento y lo que estoy leyendo ahora que googleé para colaborar con el thread, es que básicamente "todo el mundo" usa TDD "a su manera", implementando la técnica customizada para su propio consumo en su contexto de desarrollo. Muy pocos usan TDD "puro".
Sldos.
Dardo
Dardo Valdez
Jul 18, 2014, 6:32:37 PM7/18/14
to comun...@googlegroups.com
En una 2da. opinión, TDD y varias metodologías similares para generar "aplicaciones testeables" tienen cierta utilidad práctica (le sirven al developer para entender mucho mejor su código, sin dudas), sin embargo al momento en que una aplicación compleja corre, ejecuta en un ambiente de producción, las variables de contexto que no son código se suman al código "en movimiento", que interactúa con input real y datos pre-almacenados - en gran volumen en gral. - y las cosas cambian rápidamente.
Una tendencia sobre la que estuve leyendo implica que algunos sitios "grandes" - Etsy? - están experimentando con "quitar testing" y "quitar QA" en tiempo de desarrollo y en cambio trabajan la solución de problemas al estilo "hacker-Facebook", poniendo el código en producción limitada, solamente para algunos usuarios.
Ese código nuevo se monitorea detalladamente para detectar errores (claro, hay que incluir niveles de generación de información de debugging en el código: en webapps hablamos de más logs casi siempre), a la vez se monitorea el contexto: comentarios volcados por los usuarios luego de tener contacto con el código nuevo, buscando quejas en los sistemas de soporte (tickets), verificando que un cliente - usuario con password - que se conecta a un webserver siempre obtiene códigos de peticiones correctas (2xx) y si obtiene códigos de error (4xx), el ciclo completo del uso de la aplicación desde el login hasta el código de error se analiza y desglosa, integrándolo con qué es lo que hace el código del lado del servidor, se cruza esos datos con el comportamiento del SQL corrido por la aplicación, etc. etc.
Por ejemplo, de allí se puede extrapolar timeouts ocultos entre componentes que pueden estar causando que código que funciona correctamente en testings, falle en ambientes de producción. Algo que puede ocurrir cuando los sistemas - front, back, etc. - están distribuídos en colo (servers propios hosteados en algún datacenter), infra propia, y servers en alguna infra cloud.
Es fácil ver que estas técnicas van a terminar "llegando" al ámbito privado local en Argentina: porque muchas empresas y organizaciones, aunque no usen infraestructura externa alguna (ni cloud, ni hosteen hardware), sí suelen tener varios datacenters o racks de servidores geográficamente distribuídos, y cada vez es más común que los sistemas organizacionales estén distribuídos entre ellos.
Desde el punto de vista de administración de sistemas, devops, la implementación limitada a producción y el monitoreo de aplicaciones no son "tan" complejos de implementar (por ejemplo, "si alguien se conecta desde X rango de IPs, direccionarlo exclusivamente a X servidor web (vs. direccionarlo a la "granja local"/CDN) > donde está el código nuevo), sí lleva tiempo integrar el código customizado de análisis de logs, y extrapolación de datos de las métricas obtenidas (es decir, qué es lo que le vamos a pedir a Graphite que grafique).
Leí bastante sobre este tema en Code as Craft, el blog de Etsy, pero no es una metodología "formal", sino más bien una filosofía técnica de cómo encarar el trabajo.
4 Retailers Supercharging Development with DevOps
Code as Craft
Sldos.
Dardo
José González D'Amico
Jul 22, 2014, 3:14:31 PM7/22/14
to comun...@googlegroups.com
No tengo el enlace a mano pero lo vas a encontrar rápido en YouTube. Hace no mucho tiempo se armó un lindo debate en Twitter a partir de una afirmación de DHH: "TDD is dead". De esa discusión surgió la propuesta de hacer una serie de hangouts entre Kent Beck (que sabe una o dos cosas del tema :), Martin Fowler y DHH con interesantes conclusiones.
No sé si te va a responder exactamente lo que preguntás pero con seguridad te va a ayudar a echar más luz sobre el tema
Saludos
José
Reply all
Reply to author
Forward
0 new messages