Libros imprescindibles (II): The Pragmatic Programmer

El Segundo libro que hemos elegido incluir en esta serie de reseñas es The Pragmatic Programmer, de Dave Thomas y Andrew Hunt. Aunque no lo hayas leído, seguramente tengas referencias sobre él. Se trata de una de las obras que más he oído recomendar entre desarrolladores desde que se editara hace ya veinte años. Con motivo de este aniversario, de hecho, se ha lanzado una edición revisada. Es esta la que comentaremos aquí.

The Pragmatic Programmer es un texto diverso sobre los diferentes aspectos del desarrollo de software que, en opinión de los autores, deben considerarse para ser un buen programador. A lo largo de nueve capítulos, se nos presentan diferentes componentes de la disciplina, desde la filosofía que debe adoptar el programador pragmático hasta cuestiones técnicas como la concurrencia. El nivel de abstracción presentado varía según el tema, de manera que en algunas secciones encontramos ejemplos de código o herramientas concretas, mientras que otras se centran en la reflexión sobre cuestiones de más alto nivel.

El programador pragmático

Pero, ¿qué es un programador pragmático? En esencia, se trata de un profesional que se preocupa por hacer bien su trabajo. Esto es fácil enunciarlo como principio, otra cosa es llevarlo a la práctica de manera efectiva. El programador pragmático, en primera instancia, toma responsabilidad sobre lo que hace, mantiene la entropía del software bajo control, desarrolla únicamente lo necesario y mantiene su portfolio de conocimientos actualizado. También se preocupa por cuidar la comunicación con todos los implicados en el desarrollo.

Bajando un poco más a nivel técnico, el programador pragmático realiza un buen diseño de software. Para conseguir esto, sigue una serie de principios y buenas prácticas, como por ejemplo DRY (Don’t Repeat Yourself), Evitar las ventanas rotas, Ortogonalidad, Reversibilidad o desarrollo de Tracer Bullets. También es importante el dominio de las herramientas, como los editores de texto plano (como formato que resiste el paso del tiempo), el debugger y el control de versiones. Algo que siempre me ha llamado la atención es la recomendación de llevar un diario de ingeniería, donde queden registrados, además de las tareas completadas, los puntos de interés en el proceso de desarrollo (bocetos, métricas, aprendizajes, etc).

Es imposible escribir un software perfecto

La paranoia pragmática

Es imposible escribir un software perfecto. De hecho nunca está del todo bien ni, en realidad, del todo mal (siempre que funcione). Navegar en este espacio de incertidumbre genera que los desarrolladores tengan una inseguridad continua sobre lo que están haciendo. De hecho, esto es hasta algo deseable.

La paranoia pragmática nos propone un enfoque de desarrollo «a la defensiva», en el que diseñamos usando contratos, hacemos programas que fallan pronto (dead programs tell no lies) y nos protegemos de lo imposible de forma asertiva (sí, assert no es sólo para los tests).

Una reunión a la que todo el mundo tiene que acudir porque nadie está seguro del impacto que puede tener un cambio es un escenario fatal (pero a todos nos suena, ¿verdad?)

Adaptarse o morir

«La reutilización no tiene por qué ser una preocupación esencial cuando se construye software, pero pensar en qué haría falta para hacer el código reutilizable siempre debería formar parte del esfuerzo de diseño«. Con esta sentencia tan potente se subraya la necesidad de construir software flexible, fácil de modificar (bend or break). Este tema en concreto ha dado para escribir otros libros en la materia, pero se mencionan en este algunas herramientas concretas que nos pueden ayudar a conseguir este objetivo, como «Tell, don’t Ask», o evitar introducir acoplamiento con globalización o el uso incorrecto de la herencia. Estos conceptos, que vienen originalmente de la programación orientada a objetos, bien entendidos tiene aplicación aplicación genérica a cualquier paradigma.

Debemos evitar el miedo a modificar el código. Una reunión a la que todo el mundo tiene que acudir porque nadie está seguro del impacto que puede tener un cambio es un escenario fatal (pero a todos nos suena, ¿verdad?).

Otras recomendaciones técnicamente más concretas y muy útiles para conseguir un código flexible son tratar con eventos (ya que así suele funcionar el mundo real), aplicar la visión clásica del código como una transformación de datos, y contemplar principios de diseño a las configuraciones (configuración estática vs. configuración como servicio).

La reutilización no tiene por qué ser una preocupación esencial cuando se construye software, pero pensar en qué haría falta para hacer el código reutilizable siempre debería formar parte del esfuerzo de diseño

Enfrentarse a la tarea de programar

Programar es una tarea con gran impacto psicológico. Cualquiera que se haya enfrentado al desarrollo de un proyecto de software ha vivido situaciones de desempeño irregular, incertidumbre, miedo a la página en blanco o síndrome del impostor, entre otros. Es importante saber enfrentarse a uno mismo, escuchar a nuestros instintos y, sobre todo, perder el miedo a pedir ayuda y a apoyarse en el equipo.

Con respecto a las cuestiones técnicas, se hace hincapié en saber medir la eficiencia de los algoritmos, la refactorización, el testing, la seguridad y el nombrado. Estas prácticas y características se subrayan de forma recurrente en los libros más relevantes sobre desarrollo de software escritos en los últimos 25 años. Tal vez haya una razón de peso.

Todo el proyecto, de forma íntegra, debe ser considerado un proceso de toma de requisitos

El proyecto programático

Los requisitos son tradicionalmente tratados como una especie de tesoro oculto que debemos encontrar a través de una fase de análisis. Si un proyecto falla entregando valor al cliente, es porque este proceso inicial no se hizo correctamente. Esta afirmación, tan arraigada en la cultura del desarrollo, no puede ser más errónea. En la mayor parte de los inicios de los proyectos los requisitos rara vez existen con forma consistente. Deben ser refinados a través de un proceso de feedback continuo (feedback loop). Para conseguirlo, se deben establecer conversaciones, basadas en mockups o prototipos. Si lo pensamos bien, todo aquello que hacemos en software es un prototipo. Es por esto que se prefiere entregar el software en pequeños incrementos. Todo el proyecto, de forma íntegra, debe ser considerado un proceso de toma de requisitos.

Un proyecto de software se beneficia enormemente del mantenimiento de un vocabulario común, sin ambigüedad, entendido por todas las partes implicadas. Es por esto que es recomendable mantener un glosario del proyecto, al que tenga acceso todo el mundo.

Trabajar juntos es otra de las consideraciones importantes a la hora de afrontar un proyecto de forma pragmática. Los programadores, de forma natural, o tal vez por comodidad, tendemos a aislarnos. Según la Ley de Conway, el software reflejará la estructura de la organización. Si no colaboramos, el software se compondrán de silos, tanto funcionales como de conocimiento. Existen muchas formas de colaborar en equipos de software, la Code Review quizá sea la más extendida. Las prácticas más continuas como Pair Programming y Mob Programming han demostrado su eficacia a la hora de resolver determinados problemas, y conviene también darles una oportunidad.

Se hace una reseña en el libro también a Agile, y, cómo no, se menciona el entendimiento erróneo que se hace de sus principios a través de la aplicación de metodologías e implementaciones sin cuidar los fundamentos. Un proyecto pragmático favorecerá la respuesta al cambio, no primará los procedimientos sobre las interacciones, y abrazará la excelencia técnica, que nos permitirá entrar en un bucle de cambio continuo.

El software reflejará la estructura de la organización

Conclusión

Leí por primera vez este libro hace ya muchos años, cuando mi situación profesional era bien distinta por motivos de lo más variados. Recuerdo que entonces la contundencia de las ideas me dejó un profundo poso. Algunas de las metáforas y principios que se exponen han resonado en mi cabeza de forma recurrente, influyéndome sin duda en muchas de las decisiones que he tomado. Sin embargo, al releerlo en esta nueva edición, he tenido la impresión de que revisaba internamente mi entendimiento sobre muchos de estos conceptos. El libro, sin embargo, es el mismo, con alguna actualización. Es curioso cómo el texto puede llegar a impactar de forma diferente dependiendo de las circunstancias de cada uno. Sin duda se trata de una de esas obras que hay que volver a leer cada cierto tiempo. Imprescindible.

Los autores

Dave Thomas y Andy Hunt, conocidos como The Pragmatic Programmers, son dos de las voces más reconocidas en el mundo de la divulgación dentro del software. Ambos forman parte del ilustre grupo de los 17 firmantes del Manifiesto Agile, y juntos fundaron The Pragmatic Bookshelf, una editorial dedicada a la publicación de obras sobre desarrollo de software de alta calidad.