Este salseo, vamos, ha salpicado Twitter por arriba, por abajo, por todos los sitios.
¿Qué ha pasado? Este pedazo de artículo que, bueno, tiene mil likes, que tampoco...
O sea, mil likes es bastante, teniendo en cuenta aquí.
Aquí está la verdad sobre TDD.
¿Qué es TDD? TDD, Test Drive and Development, es una forma de desarrollar software basado en pruebas.
Donde tú, digamos que primero haces el test y luego haces la implementación.
Y esto es constantemente, y cada vez haces un test, falla el test, haces la implementación y así todo el rato.
Pero el tema polémico es que aquí en este artículo, amigos, dice que es una práctica fallida.
Siempre ha estado roto, está roto por su definición, su mayor mérito es el fomento de las pruebas, pero ahí termina todo.
TDD implica escribir pruebas antes de escribir el código, entonces, ¿qué hay de malo en esto?
Pues escribir pruebas para describir la intención detrás del sistema, como esperas que se comporte.
TDD implica en gran medida que debes saber cómo se comporta el sistema incluso antes de implementarlo.
Deberías saber lo que estás haciendo.
Bueno, esto es polémico porque TDD muchas veces, esta forma de desarrollar software, está más bien como visto, como una práctica donde la gente senior o gente que tenga bastante experiencia o que sabe de buenas prácticas lo hace.
Por eso aquí viene un poquito la polémica, porque viene a hundir un poco esta práctica.
La mayoría de las veces no lo haces, todos los desarrolladores que conozco no lo saben de antemano, no saben básicamente cómo se comporta el sistema antes de implementarlo.
De hecho, puedo pasar días experimentando escribiendo un MVP hasta que empiezo a comprender qué parte de mi sistema deberían ser y qué espero de ellas.
No veo a TDD como un enfoque viable en sistemas en rápida evolución, como la web.
Puede tener sentido al escribir software sistemático donde hay muy pocos cambios de un proyecto a otro.
Eso es todo lo contrario a lo que escribes en la web.
El aspecto negativo es que he visto equipos desanimados si no los siguen y esto, ahí le voy a dar la razón.
Ahí le voy a dar la razón.
Le voy a dar la razón porque sí que es verdad y esto quiero que quede muy claro.
Cualquier cosa que sea un mantra, cualquier cosa que sea una obligación, sabes como, mira, hoy he puesto este tuit.
Uno crece como programador cuando se da cuenta que a veces es mejor repetir código que usar una mala abstracción.
Que no he visto los comentarios, pero no me estrenaría que alguien me venga por aquí ya y me mate, ¿no?
Triste, pero bastante verdadero.
Mira, y aquí alguien, ¿ves?
Y aquí el bot.
El bot es mi mejor amigo.
Bueno, pues a DirtyAshley también le gusta mi tuit, pero no sé por qué quiere que me pase por su perfil.
Bueno, total, que he puesto esto, pero esto es una cosa que mucha gente se cabrea y todo.
Que tú le dices, oye, mejor copiamos el código, ¿vale?
Ashley, Ashley, vamos mejor a copiar el código que hacer una mala abstracción.
Porque una mala abstracción es muy jodida, es una...
No sale del código ni con agua caliente y las implicaciones que tiene son muy bestias.
Y cuando ya se acopla ahí y has hecho una mala abstracción o una abstracción demasiado general o una abstracción muy forzada,
pues eso puede ser lo peor que te puede caer al mundo, ¿no?
Entonces, el tema es que hay veces que las cosas no son buenas o malas.
Las cosas no te hacen de una mejor o peor programador, ni te hacen buena o mala persona, o buen o mal ingeniero.
Es como la vida, hay una escala de grises que muchas veces, no sé, porque nos gustan las cosas blancas o negras, ¿no?
Nos gustan ahí los extremos, extremos, ¿eh?
Yo soy de esto, yo de esto.
Pero la vida, como la programación, hay una escala de grises.
Y muchas veces hay que encontrar un equilibrio sobre las decisiones que tomamos, ¿no?
Y yo lo veo un poco en este post también del TDD.
En este post del TDD, muchas veces, yo lo que veo es que esta persona, Artem, que al principio parece que es una práctica fallida.
Habla de práctica fallida, pero luego reconoce que sí que hay un caso de uso, ¿no?
Que sí que dice, oye, sí que puede tener más sentido escribir software sistemático, no sé qué.
O sea, que realmente hay momentos en los que sí que puede tener sentido.
Y yo lo veo ahí.
Yo no veo que sea bueno o malo.
Yo lo que veo el TDD es una forma de desarrollar que a veces te puede venir bien y especialmente creo que el TDD puede ser muy interesante cuando estás empezando.
Cuando tú estás empezando y estás aprendiendo programación, hacer primero el test puede ser muy satisfactorio.
Ahora, trabajar 24-7 con TDD, yo personalmente, yo no lo veo.
Hay gente que es muy puritana que te dice, yo claro que sí, y la gente que no lo hace no tiene ni idea de programación y no sé qué.
Entonces, que yo creo que todo tiene su caso de uso, lo que no tiene es que todo se haga siempre igual.
El TDD igual.
Si tú solo desarrollas con TDD, pues muchas veces te vas a ver forzado a hacer TDD.
Y claro que te vas a desanimar porque normalmente si no te engancha o si no tiene sentido, pues va a ser hasta problemático.
Nunca he conocido a alguno que use TDD.
Joder, Marci, pues no has conocido a mucha gente.
A ver, hay casos de uso donde sí que creo que tiene sentido.
O sea, creo que sí que tiene sentido.
Así que ahí lo tendríamos, ¿vale?
Y luego, con el tema de las abstracciones pasa un poco lo mismo.
Yo muchas veces he visto a gente que dice, no, esto hay que abstraerlo a un método porque dry, ¿no?
Dry que significa don't repeat yourself.
Don't repeat yourself, no te repitas.
Pero claro, también muchas veces hay que tener en cuenta que hay otras, ¿no?
Por ejemplo, el kiss, keep it simple, stupid.
Jagni, you are not gonna need it.
Hay diferentes también patrones o ideas que también tienen sentido y hay veces que, digamos que chocan entre sí, ¿no?
Por eso creo que hay que ver el problema y cuando tiene sentido aplicarlo y cuando no tiene sentido, pues oye, aceptarlo con deportividad y tranquilizarse.
Así que con el TDD, con toda la que se ha liado, que había mucha gente ahí como un verdadero, y es que he visto de todo, desde gente que estaba muy a favor de este post a gente que estaba muy en contra.
Por ejemplo, John Cricket dice, está totalmente en contra de lo que ha opinado Artem, pero había otra gente que sí que decía, no, estoy totalmente de acuerdo.
Y aquí, este es el punto de Max Lynch, que estoy muy de acuerdo.
Y creo que la visión dogmática del TDD es errónea.
Para mí el valor es que para algunos problemas desarrollar en un framework puede ser mucho más rápido.
No estoy de acuerdo con que nadie diga que es universalmente superior construir cada centímetro de un software a través de TDD.
Eso es verdad.
Pero tampoco creo que sea positivo que vayamos diciendo que TDD está roto, que está mal hacer esto.
Entonces, amigos, ¿quién usa TDD religiosamente?
Bueno, te sorprendería.
O sea, Ashley, la que hemos visto antes, Ashley tiene pinta de que lo utiliza.
Entra en su perfil y te enseña cómo lo crea, cómo lo crea totalmente.
Bueno, pues eso, con el tema de TDD, amigos, tengan cuidado.
No piensen que las cosas están rotas o dejan de romperse, porque creo que a veces tiene sentido utilizar o dejar de utilizar.