Hace 9 años | Por --151124-- a genbetadev.com
Publicado hace 9 años por --151124-- a genbetadev.com

Los domingos nos gusta traerte algo curioso y/o divertido para desconectar y soltar unas carcajadas (o por lo menos sacarte una sonrisa). Hoy lo que te traemos es una tira cómica que, aunque tiene ya un tiempo, lo cierto es que muestra una realidad como un templo: aunque parezca que los programadores estamos muchas veces en el país de las musarañas, realmente estamos pensando muy fuerte y muy duro en resolver un problema...

Comentarios

delawen

#14 #15 #20 #25 #27 El TDD sólo sirve cuando la idea ya está avanzada. Si lo que estás haciendo es diseñar un componente desde cero, desde la idea abstracta, es absolutamente inútil.

TDD está bien para los desarrolladores puros, a los que se les dan las estructuras ya pensadas y lo "único" que tienen que hacer es programar (nótense las comillas en "único", no estoy despreciando esta tarea en absoluto). No han sido pocas las veces que he visto usar TDD para sistemas completamente nuevos y al final acabas programando dos veces: primero los tests, luego la implementación inicial, luego rehaces los tests porque te has dado cuenta de que necesitabas otras APIs diferentes y luego, finalmente, la implementación que encaje con los nuevos tests.

drwatson

#29 que es un desarrollador puro??? creo que en cualquier proyecto en el que trabajes todo el mundo es desarrollador.
TDD funciona muy bien para fases iniciales, pero hay que saber escribir tests y saber lo que se quiere conseguir y eso no todo el mundo sabe hacerlo

ktzar

#29 El TDD sirve todo el rato,... TDD no significa que los tests no se puedan cambiar más adelante, borrar, o combinar... La idea del TDD es que no es sólo útil para que tu aplicación esté probada, sino para ayudarte a establecer un ciclo de trabajo y a pensar, antes de picar código, qué demonios es lo que quieres hacer.

Lo que es una tontería es ser super estricto y estar haciendo tests para cada pequeña porción de lógica que añades, pero pensar "outside-in" en lugar de "inside-out" es muy útil a la hora de hacer código que sea cómodo de usar.

Cuántas veces, antes de empezar a programar una clase, hemos hecho un pequeño boceto en código de cómo usaríamos esa clase... Pues bien, una vez esta uno acostumbrado a escribir tests, ese código que uno luego tiraría a la basura, lo hace en formato test, y esto ayuda muchísimo a ir hilando ideas...

Y como dice #30 no todo el mundo sabe hacer tests, y para mucha gente esto es poco productivo. Pero a mi me funciona para el 50-60% de código que hago... El truco es tener 10-15 estrategias distintas a la hora de afrontar algo, de plantearse cómo testearlo. No todo tiene que tener 20 mocks y 200 tests. Y no hay que ser talibán ni de TDD ni de lo contrario (no tener ni un santo test). A veces, con escribir 4 o 5 tests inicialmente para un código en el que trabajarás 4 horas es una aproximación muy válida. No siempre hay que tener esos mini-ciclos de un test, al menos es mi opinión, que eso no funciona para todo tipo de códigos.

Por ejemplo, el otro día programando el código de pathfinding de un juego, pues hacer TDD me ayudó a establecer qué formato iba a dar a los nodos y segmentos, y qué cosas iba a esperar... Fue entonces cuando me fui dando cuenta de cuándo quería ids de nodos, y cuándo píxeles... Si no hubiera hecho los tests primero, me habría dado cuenta a medias y tendría que haberlo cambiado todo 3 ó 4 veces.

delawen

#30 (y #32 y #34) Desde mi punto de vista, un desarrollador puro es alguien a quien le dan las interfaces/objetos/esquemas ya hechos y "sólo" tiene que modelarlo en la tecnología escogida.

No todo el mundo programa ni todo desarrollador hace sólo programación. De ahí lo de "puro". Alguien que sólo desarrolle, o sea, que sólo programe.

Te pongo un ejemplo que he tenido hace poco: estábamos tratando con crowdsourcing y necesitábamos un componente que pudiera verificar cómo de fiables eran los diferentes datos que se estaban subiendo. Todavía es una idea abstracta, no puedes definir ni tests ni interfaces ni nada. Ni siquiera tienes claro qué tipos de entradas y salidas vas a necesitar.

Durante las primeras horas (o días o incluso semanas), lo único que vas a hacer es leer fuentes, pensar, hacer algún esquema no muy concreto y hablar con gente que creas que puede aportarte ideas.

Ahí ni el TDD ni ninguna técnica de programación podrá ayudarte. Estás sólo tú con tus ideas felices.

TDD sólo sirve cuando la idea ya está avanzada, esquematizada y repensada. Que yo no sé vosotros, pero en mi trabajo eso suele ser menos de la mitad del tiempo.

a

#33 TDD sólo sirve cuando sabes lo que quieres hacer, como cualquier otra técnica de programación del mundo. De todos modos en ocasiones una aproximación con BDD y tratando de definir ejemplos de lo que quieres ayuda bastante, y si lo haces bien esos mismos ejemplos posteriormente se convierten en las pruebas de aceptación de tu sistema. Luego, la idea del "programador" como alguien que codifica en base a un diseño entregado por otro, vamos el waterfall de toda la vida, hace siglos que esta desterrada de cualquier equipo de programación medianamente competente, the design is the code decía jack reeves hace muchos, muchos años (dale al google y leete los artículos).

#32 En problemas puramente algoritmicos TDD no ayuda al diseño de algoritmos, para eso existen tecncias de algoritmia, en estos casos puede ser suficiente con tener algunos test iniciales y usarlos simplemente como método de comprobación para saber cuando hemos terminado, pero no como técnica de diseño del propio algoritmo, esto quedo bastante claro con el famoso asunto del sudoku y Ron Jeffries (uno de los integrantes del equipo original del proyecto C3 con Kent Beck donde se empezo a utilizar esto del TDD). Para el resto de problemas la aproximación en baby steps suele dar buenos resultados, tu código crece de manera mucho más sana, sobre todo si haces buen uso de la fase de refactor.

delawen

#36 EFfectivamente, TDD sirve cuando el proyecto ya está avanzado. Luego, volviendo al tema inicial del hilo, ni TDD ni hacer dibujitos ni nada similar te puede ayudar a la hora de simular ante los demás que estás trabajando más que cuando te sientas sencillamente en la silla (o vas andando, a mi me ayuda andar) mirando al infinito.

t

#29 Hombre, si te pones a picar código a lo loco, sin pensar un poco antes lo que quieres hacer y cómo estructurarlo, pues claro que no funciona. Pero es que tampoco te va a funcionar de otra manera, el código va a ser una locura hasta que se estabilice.

Llevamos 50 años de ingeniería del software por algo. Lo de ponerse a picar sobre la marcha puede servir para un script de tres al cuarto, pero para poco más.

ikipol

No aporta absolutamente nada a la fuente original http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer

D

#1 Ya citan la fuente, difundir algo no es copiar/plagiar. En cualquier caso igual me da cambiarlo

eltxoa

#1 Lo traducen, no?

D

Mejor que el cartel de do not disturb es el que yo tengo.

Silence! I kill you!

D

#4 ¿ Los tiburones duermen ? lol lol lol

Gargonslipfisk

#5 Delfines, que los tiburones son peces

D

#6 Venga, voy a preguntarlo de otra forma ¿ acaso los peces no duermen ?

Gargonslipfisk

#40 Eso es ser mala gente Estás forzando un razonamiento falaz al descontextualizar mi comentario.

Ppgol

#24 El problema es esa gente que te envía un correo y si no le contestas en 5 minutos, te llama por teléfono para asegurarse que lo has leído

delawen

#26 También hay formas de educar a ese tipo de gente que cree que sólo existe la comunicación síncrona.

Desde una contestación automática al correo que diga "lo he recibido, no me llames para comprobarlo porque lo he recibido copón", tardar varios tonos en contestar (y que de mientras se plantee si es tan importante saber si leiste o no el correo, haciéndole perder a él también el tiempo),... O, simplemente, diciéndoselo: "si esta llamada ha sido sólo para comprobar si me ha llegado el correo, me has hecho perder el tiempo".

A un jefe hay pocas cosas que le pongan más nervioso que que le digas que ha hecho algo que te ha hecho perder el tiempo. O que otra persona te está haciendo perder el tiempo.

También está la opción de no poner teléfono a según qué horas y que sólo haya mensajería instantánea. Al final se acaban acostumbrando y todos mejoran.

pradhesa

#26 Estoy un poco quemado con ese tema en particular, y en general con todo el tema de las interrupciones.
#28 Tomo nota de eso que dices.

D

#2 "¿Silencio, yo matar tú?"

timonoj

#8 La referencia es a esto.

D

El TDD es la mierda. Pasaba por aqui.

Despero

Esto es en general para cualquier trabajo en el que se requiera un poco de elucubración y una cadena de pensamientos. Cuando te rompen el tren de pensamiento, tienes que empezar desde cero.

Joaqui

Nada mas fácil que coger papel y boli para evitar esas cosas...

D

#10 Ayuda bastante, sí. Pero no puedes escribir el flujo de ejecución de cualquier cosa.

Joaqui

#11 Antes de sentarse a programar hay que escribir, eso es lo único que digo, ni flujo de ejecución ni nada, las ideas al papel.

ktzar

#13 El papel es tan de los 2000... Ahora, antes de escribir código, deberías empezar por tus tests. Así no se te olvida lo que estás haciendo:

- Test, que falle
- Lo arreglas, commit
- Otro test, que falle
- Lo arreglas, commit

Así, te interrumpan cuando te interrumpan, puedes seguir donde estabas, ya que un test incluye bastante de lo que pensabas hacer en el código y a veces cómo pensabas abordarlo.

Típico test que está sin solucionar:

```js
var popup = popupModule.createPopup('#popup', '#trigger');
$('#trigger').trigger('click');
expect($('#popup').is(':visible').toBeTruthy()
```

Cuando me encuentro ese test que falla, sé perfectamente qué es lo que tengo que implementar.

ED209

#14 cuando tienes que diseñar algo con cierta estructura el TDD (en el sentido estricto red->green->refactor) no ayuda. Lo que ayuda es el papel y boli.

ktzar

#25 Tienes razón que en el sentido estricto no funciona del todo bien a la hora de diseñar algo. Pero por ejemplo, siempre se dice que diseñar un API es la mejor forma de diseñar un sistema, ya que ayuda a la hora de buscar qué tipo de uso se le va a dar al sistema.

Pues bien, si en lugar de usar papel y boli, se hace una base de datos y se programa un cliente del api en forma de unit tests (o tests de comportamiento), ese cliente (que se podrá ir cambiando, claro) es una documentación, una hoja de ruta perfecta. Y es cierto que en ese caso, lo ideal es ir en grupos de tests, no de uno en uno.

nanobot

Oh sí, que todas las putas páginas te obliguen a estar haciendo scroll hacia abajo todo el rato que parece que estás buscando algo en una biblioteca que sólo tiene pergaminos, es hacer del mundo un lugar mejor, sí.

No te jode...

a

En realidad en cualquier trabajo que exija concentración y tenga cierta complejidad las interrupciones son mortales, hay que contar el tiempo de la interrupción+el tiempo de volver al estado anterior a la interrupción que, depende muchisimo de la persona y la complejidad de la tarea, y en algunos casos pueden ser muy grandes. Por eso el telefono o las oficinas diafanas donde la gente tiene que aislarse para concentrarse son una muy mala idea.

Las típicas oficinas llenas de gente con cascos para aislarse y concentrarse, si lo piensas un poco es ridículo que en un espacio creado para el trabajo, la oficina, se tengan que usar mecanismos precisamente para aislarse del ruido que se genera en ese espacio, es el mundo al reves, una oficina sana debería ser un espacio ideal para el trabajo no lo contrario.

No es nada nuevo esto, en peopleware, uno de libros clásicos del desarrollo de software, ya se comentaba esto hace más de 20 años.

j

juas, menudas peloteras he tenido con mi pareja por culpa de esto:
Trabajo desde casa y muchas veces me preguntaba cosas que podrian esperar o podria solucionar ella misma... pero ya le dije que no lo hiciera, que me jode como una hora o dos horas de curro a veces y cuestra arrancar despues de esto...
Ahora cuando vamos a comer o ir a comprar o algo asi le digo espere que tengo que guardar la partida (pongo todo lo que puedo en papel) o termino lo que estaba haciendo.

mucho mejor ahora.

Mister_Lala

Al leer esta entrada sólo he podido recordar esa escena de los Simpsons de "lisa necesita un aparato ¡Seguro dental!" donde Homer pierde la concentración cuando le meten un lápiz en la hucha.

ElPerroDeLosCinco

El problema es que le faltan los paréntesis en la condición.

Relator

Yo soy el artista de la pista y suscribo la viñeta como algo que muchos jefes y no jefes deberían tener encima de sus mesas a primera hora de la mañana.

f2105

Interrumpir a un desarrollador mientras está profundamente concentrado en código, es cómo interrumpir una eyaculación.

D

#21 Creo que un desarrollador trabaja con otros dispositivos de entrada y salida, y también crea flujos de un tipo diferente.