El pintor de batallas, de A. Pérez-Reverte

En esta corta novela de algo menos de 300 páginas, poco para lo que Pérez-Reverte nos tiene acostumbrados, realizaremos un breve recorrido por algunas de las guerras de nuestra era moderna: Sierra Leona, Kuwait, y por supuesto Sarajevo, almacén de recuerdos y experiencias del propio autor, en su época de reportero de guerra.

La historia, de escaso argumento novelístico pero gran trasfondo documental, narra la historia de un fotógrafo de guerra retirado que se dedica a pintar un enorme mural en el cual trata de representar la Guerra. La Guerra con mayúsculas, la Guerra en general, la Guerra a través de los tiempos, desde Troya a los Balcanes, pasando por las guerras medievales. Matanzas, violaciones, vidas cercenadas por un objetivo que nunca queda lo suficientemente claro. Y la vida de este personaje da un vuelco cuando aparece un viejo objetivo del pasado, una foto, un retrato de un futuro crimen. Y junto a él, fantasmas del pasado. Recuerdos, vivencias, nostalgia y dolor, mucho dolor.

Es una novela dura, cruda, implacable, que muestra sin pudor alguno el horror de la guerra. A lo largo de sus capítulos, el autor nos sumerge, desde la perspectiva de un fotógrafo de guerra retirado, en los terribles acontecimientos vividos en una guerra. Edificios derruídos, destrucción por doquier, campos de concentración, mutilaciones, tortura, muerte y sangre; “¿cómo es posible que el cuerpo humano acumule tanta sangre? Cinco litros, dicen, ¿no?”

Los diálogos son más bien una excusa para compartir con el lector experiencias de guerra, pero sobre todo experiencias humanas. Del género humano, vaya. Ese género que siempre parece abocado a la autodestrucción. Es una novela de las que hacen reflexionar, de las que dan que pensar sobre nuestras acciones y el efecto de las mismas; nos hace pensar en que nadie en esta vida es expectador inocente; todos somos, queriendo o sin quererlo, víctimas y verdugos a la vez.

El estilo es un tanto complejo: no hay una diferenciación clara de párrafos, sino que la exposición es bastante contínua, y en los diálogos se mezcla estilo directo e indirecto de forma magistral. Ello le da mucho dinamismo a la lectura, y mucha naturalidad a los diálogos. Giros y frases largas y de construcción compleja nos revela la experiencia de este académico de las letras. En cuanto al desarrollo de la trama, la novela comienza aglutinando un conjunto borroso de bultos e imágenes que poco a poco se van revelando, hasta que, al final de la novela, la historia queda completamente nítida.

El pintor de batallas, una novela que nos muestra el monstruo que todo ser humano lleva dentro, y que salta cuando se nos presiona lo suficiente, cuando todo depende de sobrevivir o perecer.

Test Driven Development: Conceptos

Entre la maraña de metodologías ágiles de desarrollo de proyectos software, se encuentra esta metodología, propuesta por Kent Beck (Extreme Programming, entre otras metodologías ágiles, toda una eminencia en este campo). En los siguientes artículos desarrollaré los conceptos de esta técnica y los patones asociados a la filosofía TDD. Espero que a alguien le resulte útil.

Conceptos

Test-Driven Development se basa en dos máximas:

  1. escribe código nuevo solamente si tienes primero un test automático que falla; y
  2. elimina la duplicación.

Esto implica:

  • Diseñar organizadamente, haciendo que el código que funciona retroalimente las nuevas decisiones de diseño.
  • Escribir tus propios tests, ya que no puedes esperar a que lo haga otro por tí.
  • El entorno de desarrollo debe proveer de respuestas rápidas a pequeños cambios.
  • Tus diseños deben consistir en componentes fuertemente cohesionados y débilmente acoplados para poder probarlos fácilmente.

El “mantra” TDD establece cómo escribir los test en tres fases: rojo-verde-refactor.

  1. Rojo: escribe un test rápidamente, pequeño, que quizá ni funcione ni compile.
  2. Verde: haz que el test funcione rápidamente, cometiendo los errores de diseño que sean necesarios en el proceso. Tu obsesión: la barrita verde que significa que el test ha pasado.
  3. Refactor: elimina errores de diseño introducidos.

TDD trata de acometer el miedo a no ver el final de un proyecto, reconduciéndolo a un “¡ten cuidado!, mejor vamos paso a paso”. El miedo conduce a tomar soluciones tentativas, a comunicarse menos, impida la retroalimentación en el desarrollo y te convierte en un gruñón. Cada paso que se da debe asegurarte sobre tu posición para tomar impulso hacia el siguiente paso. Al final, el desarrollo debe convertirse en una secuencia de pasos seguros. Kent Beck pone un ejemplo muy bueno para entender el proceso de TDD: imaginemos que tenemos que sacar agua de un pozo. Podemos utilizar una polea lisa y tirar de la cuerda sin soltar hasta que el cubo sale completamente. Utilizar TDD en este proceso equivaldría a utilizar una rueda dentada que nos permite siempre avanzar pasito a pasito, estar sobre seguro, de manera que si en cualquier momento soltamos la cuerda el cubo no se precipita de nuevo al vacío y no hay que volver a empezar. Cada paso que se da se sustenta en la seguridad del paso anterior.

TDD tiene como limitación el que no permite asegurar objetivos de seguridad y concurrencia. Simplemente no sirve.

Procedimiento: 1º se escribe el test; 2º se escribe el código. ¿cómo?

  1. Añade rápidamente un test, sin preocuparte por el diseño.
  2. Ejecuta todos los test y observa cómo el test falla.
  3. Cambia el código del test para que pase.
  4. Ejecuta todos los test y observa como todos los tests pasan.
  5. Refactoriza e ltest para eliminar la duplicación y mejorar su diseño.

Consejos:

  • Empieza probando lo más básico y sencillo.
  • La duplicación de código es el síntoma de que hay dependencias que eliminar.
  • Comienza pensando qué cosas hay que probar; haz una lista e implementa un test para cada elemento de la lista. Ocurrirá que, a medida que implementas los tests, se te ocurrirán nuevos test; con lo cual la lista es dinámica.
  • Si en un determinado momento no sabes cómo acometer el siguiente paso, no lo des: divide dicho paso en otros más sencillos y impleméntalos uno a uno. Si el siguiente paso (o los siguientes pasos) son intuitivamente sencillos, puedes juntarlos y dar un paso más grande. El tamaño del paso a dar no es estático, sino adaptable a la información que tenemos, al riesgo y a la sencillez del paso a dar.

Para implementar la técnica de TDD de forma efectiva los test tienen que tener dos características fundamentales:

  • los test tienen que pasar rápidamente, o no se pasarán con la frecuencia apropiada que dicta el método.
  • los test tienen que estar aislados totalmente entre sí; el resultado de uno no debe jamás afectar a otro test, o de lo contrario no servirán para nada porque pueden dar una falsa sensación de seguridad.

He tratado de ser lo más esquemático posible para que se entiendan bien las ideas. En siguientes entregas explicaré brevemente algunos patrones relacionados con la metodología de Test-Driven Development (¿se entiende ahora lo de desarrollo dirigido por pruebas?).


Referencias:

“Test-Driven Development by Example
Kent Beck