Hola Habr!
Les traigo a su atención una traducción del artículo "
Simple Hickey " de Robert C. Martin (tío Bob).
Rich Hickey pronunció una excelente conferencia sobre Strange Loop titulada Simple, Easy. Le recomiendo que pase una hora escuchándolo. Esta actuación vale cada segundo.
Habrá algunas cosas en esta conferencia con las que no esté de acuerdo. Cuando esto suceda, deténgase y piense, piense en serio, ¿realmente no está de acuerdo? Quizás no deberías pensar que esto es así.
Por ejemplo, Rich dice algunas cosas aparentemente despectivas sobre TDD y Agile and Refactoring, las vacas sagradas de la Comunidad Agile. Si está comprometido con esta comunidad, puede reaccionar negativamente. No es necesario Rich no descuida la práctica. Descuida la religión, la imprudencia, la frivolidad.
Rich compara pruebas unitarias con rieles de seguridad. Entonces él hace un muy buen punto. Él dice que cuando tiene un error, entonces este error pasó sus pruebas. ¿Y ahora que? Ahora debería encontrar el error. Y si el sistema no es simple, no será fácil. (Tenga en cuenta que usé las palabras aquí de manera simple y fácil. El comienzo del discurso de Rich está relacionado con las diferentes definiciones que tienen estas palabras. Le sugiero que se detenga en este lugar y escuche los primeros diez minutos de su discurso, y luego vuelva a este párrafo nuevamente).
Rich enfatiza que los velocistas corren rápido, pero no por mucho tiempo. Luego dice que Agile "resolvió" este problema simplemente disparando la pistola de arranque una y otra vez en rápida sucesión. Él sonríe y el público se ríe. Luego continúa diciendo que el sprint continuo no necesariamente hace que los sistemas sean simples, y la simplicidad es la clave para acelerar.
Por supuesto que tiene razón. Martin Fowler habló sobre esto en su artículo "Flaccid Scrum". Y eso es lo que muchos de nosotros en la comunidad ágil hemos expresado. Tales iteraciones cortas sin buenas prácticas técnicas no conducen a un desarrollo rápido. Más bien, lleva a un desastre.
Rich se ríe de la idea de que un conjunto de pruebas le permitirá cambiar el código. Él dice que las pruebas son una red de seguridad, nada más. Los TDDers sabemos que es necesario un conjunto de pruebas si queremos cambiar el código sin miedo. Pero Rich tiene razón sobre la red de seguridad. Un sistema de seguridad puede ayudarlo a simplificar su sistema si ya es simple. Pero un sistema de seguridad bajo un gran fajo de tierra tendrá poca ayuda para resolver el desastre. Oh, no me malinterpretes. Necesito estas pruebas! Pero el trabajo no será fácil. (De nuevo esta palabra).
Aquí hay otra charla de Rich: Hammock Driven Development, en la que nos anima a pensar, y no solo a escribir fragmentos de código.
Entonces aquí está. Rich está preocupado, y con razón, de que tengamos una cultura compleja. Cuando se establece una tarea para los programadores, corren hacia adelante y escriben una gran cantidad de código confuso, utilizando marcos y herramientas "simples", sin darle al problema el significado adecuado. Lo que confundimos ligereza con sencillez. (Por ejemplo, Rails es fácil, pero no es fácil). Su queja sobre las pruebas es que las usamos para reemplazar los pensamientos. Lo cual es bueno para nosotros, porque escribimos las pruebas, pero de hecho no dedicamos suficiente tiempo al problema que merece. No simplificamos el problema. Acabamos de hacer lo que fue fácil.
Entonces, en verdad, la comunidad Agile y toda la comunidad de software están infectadas con esta enfermedad. Con demasiada frecuencia hacemos lo que es fácil, debido a lo que es simple. Y entonces hacemos un desastre. Pero ese no es el valor de la agilidad ahora y nunca lo será. ¡Y esto, por supuesto, no es el valor del dominio del software! De hecho, hacer lo que es simple, a diferencia de lo que es fácil, es una de las características definitorias de un asistente de software.
Al final, creo que la percepción TDD de Rich está distorsionada por lo que ve en la industria. Honestamente, creo que se perdió algunos detalles. Y creo que él entendería que esta práctica sería tan útil para él como para mí. No como una forma de evitar pensar y meterse en un lío, sino como una forma disciplinada de ser detallado, cuidadoso y reflexivo.
Ahora pregúntese qué significa TDD para usted. ¿Es TDD la disciplina que usa para facilitar las cosas? ¿O es una disciplina que usas para ser reflexivo, cuidadoso y no complicarte?