5 conclusiones esenciales del libro “The Pragmatic Programmer”

The Pragmatic Programmer se publicó por primera vez en 1999 y desde entonces ha sido nombrado el mejor libro de programación de todos los tiempos.

Los autores Andy Hunt y David Thomas se encontraban entre los autores originales del Manifiesto Ágil y tienen algunas credenciales serias. El libro ha logrado una calificación promedio de 4.3 en Goodreads de más de 16,000 calificaciones. Basta decir que es uno de esos libros que todo programador debería leer.

En esta revisión, voy a condensar el libro en cinco conclusiones esenciales.

Don’t Repeat Yourself

Thomas acuñó el término “DRY” (no se repita), una de las reglas más útiles para lograr un código de alta calidad que jamás haya existido. Los autores definen el principio DRY de la siguiente manera:

“Cada pieza de conocimiento debe tener una representación única, inequívoca y autoritaria dentro de un sistema”.

En el libro, dan el siguiente ejemplo como código no DRY:

def print_balance(cuenta)
   printf "Debitos: %10.2f\n", cuenta.debitos 
   printf "Creditos: %10.2f\n", cuenta.creditos
   if cuenta.fees < 0
     printf "Fees: %10.2f-\n", -cuenta.fees
   else
     printf "Fees: %10.2f\n", cuenta.fees 
   end
   printf " ———-\n" 
   if cuenta.balance < 0
     printf "Balance: %10.2f-\n", -cuenta.balance
   else
     printf "Balance: %10.2f\n", cuenta.balance
   end
 end

Esto luego se refactoriza a la siguiente versión DRY:

def format_amount(value)
   result = sprintf("%10.2f", value.abs) 
   if value < 0
     result + "-" 
   else
     result + " " 
   end
 end
 def print_line(label, value)
   printf "%-9s%s\n", label, value
 end
 def report_line(label, amount)
   print_line(label + ":", format_amount(amount))
 end
 def print_balance(cuenta) 
   report_line("Debits", cuenta.debits) 
   report_line("Credits", cuenta.credits) 
   report_line("Fees", cuenta.fees) print_line("", "———-") 
   report_line("Balance", cuenta.balance)
 end

En el segundo fragmento, se elimina la duplicación de constantes. Las líneas equivalentes se encapsulan en funciones independientes para imprimir, formatear y generar informes.

Curiosamente, esto en realidad da como resultado más código. Sin embargo, el resultado es más legible, fácil de mantener, comprobable y escalable. El principio DRY podría verse como un medio para lograr estos otros resultados.

Los autores enfatizan que DRY no solo se trata de evitar la duplicación literal de código. Esta es solo una pequeña parte de la imagen. Escriben:

DRY se trata de la duplicación de conocimientos, de intenciones. Se trata de expresar lo mismo en dos lugares diferentes, posiblemente de dos formas totalmente distintas.

La duplicación podría estar en representación, estructuras de datos, diseño de API o incluso podría referirse a un esfuerzo duplicado entre los miembros del equipo. Este último es un tema de gestión que se analiza más adelante en el libro.

La mentalidad es tan importante como el conocimiento

A diferencia de los libros de programación típicos, gran parte de The Pragmatic Programmer no se trata del código en sí, sino de la mentalidad y la filosofía del programador.

Mucho de lo que se discute se reduce a pensar en el desarrollo de software de manera más general como un proceso de extremo a extremo en lugar de simplemente hacer zoom en el código. Esto tiene sentido. Después de todo, a los programadores no se les paga por escribir código sino por producir software que funcione.

Algunos aspectos importantes de esta mentalidad incluyen:

• Asumir la responsabilidad de su trabajo al no poner excusas ni culpar cuando las cosas van mal.
• Escribir software que sea “lo suficientemente bueno”. Esto significa no perder el tiempo en cosas que son mejores de lo necesario para que el producto tenga éxito.
• No ignorar la deuda técnica. Los autores utilizan la analogía de las ventanas rotas para esto:

No deje “ventanas rotas” (malos diseños, decisiones incorrectas o código deficiente) sin reparar. Arregle cada uno tan pronto como se descubra. Si no hay tiempo suficiente para arreglarlo correctamente, encárguelo. Tal vez pueda comentar el código ofensivo, mostrar un mensaje “No implementado” o sustituir datos ficticios.

Encuentro interesante este último punto. Los autores no dicen que el código deba ser perfecto, sino que debe mantenerse en una condición en la que no se deteriore. Una ventana tapiada puede no verse muy bien, pero evita que se acumulen muchos otros problemas con el tiempo.

Un buen código es fácil de cambiar

Para mí, posiblemente la conclusión más importante de The Pragmatic Programmer es el principio Easy to Change (ETC).

¿Con qué frecuencia, como programadores, recibimos cambios en la interfaz de usuario de un diseñador o nuevos requisitos de los clientes que significan volver a implementar la funcionalidad existente? Básicamente todo el tiempo. Sí, en un mundo ideal, obtendríamos un diseño completamente considerado desde el principio que podemos convertir en un código perfectamente elaborado, pero el mundo real no funciona así.

El principio Easy to Change resuelve este problema. Se afirma que:

Un buen diseño es más fácil de cambiar que un mal diseño.

Los autores presentan esto como un valor rector del que se derivan muchos otros principios de la ingeniería de software. Específicamente, gran parte de SOLID podría considerarse un caso especial de ETC.

¿Por qué es bueno el desacoplamiento? Porque al aislar las preocupaciones hacemos que cada una sea más fácil de cambiar.

¿Por qué es útil el principio de responsabilidad única? Porque un cambio en los requisitos se refleja en un cambio en un solo módulo.

¿Por qué es importante nombrar? Porque los buenos nombres facilitan la lectura del código y tienes que leerlo para cambiarlo.

Si escribe código teniendo en cuenta la posibilidad de cambiar, la próxima vez que un diseñador revise el diseño, ¡la vida será mucho más fácil!

Elija excelentes herramientas y conviértase en un experto con ellas

Joel Spolsky escribió que los programadores deberían tener “las mejores herramientas que el dinero pueda comprar” para ser completamente productivos. El Programador pragmático se alinea con esta noción y tiene un capítulo completo dedicado a las herramientas.

Las herramientas amplifican su taletno

Debo admitir que me obsesioné tanto con encontrar las mejores herramientas que parte de este capítulo me pareció un poco obvio, pero fue reconfortante que mis suposiciones se reafirmaran. Los puntos clave son:

• Mantenga el conocimiento en texto sin formato. Según los autores, esto significa texto “comprensible para los humanos”. Esto incluye HTML, JSON, etc. El razonamiento es que es más sostenible que los formatos binarios y más fácil de manipular con scripts y otro software.
• Utilice siempre el control de versiones. Los autores argumentan que el control de versiones debe usarse para cualquier proyecto, incluso cuando se trabaja solo en su computadora local.
• Domina tus herramientas con fluidez. Como desarrollador, es tentador seguir evaluando constantemente nuevas herramientas y cambiando entre ellas. Si bien esto puede tener algún valor, a menudo es mejor dominar las herramientas que ya tiene

Probablemente ágil no es lo que crees que es

Ambos autores de The Pragmatic Programmer participaron en la redacción del Manifiesto Agile original. Por lo tanto, esperaba un capítulo sobre una metodología ágil preferida: SCRUM o tal vez Kanban. Pero no existía tal cosa. De hecho, critican activamente las metodologías rígidas y sus certificaciones asociadas:

Muchos programas de certificación son incluso peores […]: se basan en que el estudiante sea capaz de memorizar y seguir las reglas. Pero eso no es lo que quieres. Necesita la capacidad de ver más allá de las reglas existentes y aprovechar las posibilidades para obtener ventajas. Esa es una mentalidad muy diferente de “pero Scrum / Lean / Kanban / XP / ágil lo hace de esta manera …” y así sucesivamente.

En cambio, sugieren que los desarrolladores tomen las mejores piezas de una variedad de metodologías y las adapten para su uso, defendiendo lo que ellos llaman The Essence of Agility.

Lo que esto significa en la práctica es que nunca puede haber un “proceso ágil” porque, por definición, ser ágil se trata de “responder al cambio”. Según los autores, las decisiones de gestión de proyectos siempre deben ser contextuales, dependiendo de su empresa, la naturaleza del equipo y muchos otros factores. Ningún proceso predefinido puede tener en cuenta todo esto.

Entonces, ¿qué significa esto en la práctica? ¿Cómo se pueden gestionar los proyectos? El Programador pragmático proporciona tres pasos brillantes y universales:

• Calcule dónde se encuentra.
• Da el paso más pequeño y significativo hacia donde quieres estar.
• Evalúa dónde terminas y arregla todo lo que rompiste.

Sugieren repetir estos pasos hasta que haya terminado y utilizarlos de forma recursiva en todos los niveles de todo lo que hace.

Conclusion

Como habrá deducido de esta reseña, The Pragmatic Programmer no es realmente un libro sobre programación. Es un libro sobre la creación de software funcional. Esto requiere muchas otras habilidades además de escribir código.

Entrar en cada detalle está más allá del alcance de este artículo, pero también hay excelentes consejos sobre:

• Estimación
• Análisis de requerimientos
• Refactorización
• Pruebas
• Creación de prototipos y muchos aspectos de la codificación

Si tengo una pequeña crítica, es que el libro no tiene un tema central sobre lo que significa ser “pragmático”. Se siente más como una larga lista de aforismos entretejidos con explicaciones de apoyo. Sin embargo, estos son algunos aforismos de clase mundial y, en general, este libro es una lectura esencial para cualquier desarrollador.