El programador pragmático – Consejos para ser mejor desarrollador WordPress

Voy a empezar confesándote algo: desde que me suscribí hace unos meses a Netflix, mi ritmo de lectura ha bajado sustancialmente. Y es que buena parte del tiempo que antes dedicaba a leer una novela cualquiera ahora lo dedico a ver series ?. Supongo que es más fácil desconectar así… Pero me sigue gustando muchísimo leer y, por ello, siempre intento buscar huecos en mi agenda para devorar algunas páginas. A veces con el objetivo de entretenerme, otras para aprender.

Recientemente he leído un libro llamado «El programador pragmático: de aficionado a maestro» (en inglés; no sé si existe versión en español), de Andrew Hunt y David Thomas. Llevaba ya un tiempo buscando algún libro sobre buenas prácticas de programación y consejos varios, así que cuando lo encontré y vi que tenía buenas opiniones en internet, decidí comprarlo (junto con otro llamado Clean Code, del que hablaré más adelante… cuando lo haya leído ?). Como el libro me ha parecido ameno e interesante, he decidido explicarte un poco de qué va y cómo está organizado, compartir algunos de los consejos que más me han gustado y comentar por qué creo que leerlo te ayudará a ser mejor desarrollador WordPress.

Un vistazo al libro

Con tan solo 260 páginas, El programador pragmático es un libro que se deja leer fácilmente. Pero que no te engañe su «brevedad»: aunque el contenido esté escrito de forma amena y comprensible, los conceptos que explica no son sencillos de asimilar, así que evita leerlo de una sentada. Lo mejor que puedes hacer es empezar con una lectura en diagonal para familiarizarte con sus contenidos y luego ya, si eso, profundizas en los temas que más te interesan en ese momento. Para mí, este tipo de libros son «de referencia»; me gusta saber de qué van y tenerlos a mano para que me ayuden a resolver cualquier duda puntual que me pueda surgir.

El libro es una colección de «casos» o «ejemplos» en los que se explican situaciones típicas a la que nos podemos enfrentar y cómo podemos combatirlas. Por ejemplo, uno de los temas que se discuten en el capítulo 2 (cuya traducción libre podría ser «cómo trabajar de forma pragmática») son los males de la duplicación. Todos sabemos que «no hay que repetir código», ¿verdad? «Si tienes que repetir algo, ponlo en una función y úsala a ella en lugar de copiar y pegar líneas de código» es la típica frase del compañero de turno…? Pues bien, el libro profundiza mucho más sobre qué es la «duplicidad»: duplicar el conocimiento en código, comentarios y documentación, duplicar componentes por cuestiones de arquitectura tipo cliente/servidor, etc. En definitiva, da una perspectiva muy detallada de cosas que quizás ya sabes, pero en las que no siempre reparas.

Todos los casos están agrupados en los siguientes capítulos:

1. Una filosofía pragmática. Se trata de un capítulo introductorio donde los autores explican qué rasgos debería tener un programador pragmático.
2. Cómo trabajar de forma pragmática. Conjunto de recomendaciones y trucos básicos para mejorar tus habilidades. En este capítulo se tratan temas como duplicidades, prototipos, estimaciones…
3. Las herramientas básicas. Recomendaciones de herramientas que deberías saber usar en tu día a día y el por qué de su utilidad. Escribir en texto plano, usar un sistema de control de versiones o integrar generadores de código en tu flujo de trabajo son algunos de los ejemplos que tratan.
4. Paranoia pragmática. Uno de los capítulos más interesantes, trata sobre las «imperfecciones» del código: tenemos que aceptar que el código no será nunca perfecto… pero eso no debería ser ni un impedimento ni un problema. Aquí encontrarás ejemplos para reducir (que no eliminar) esas imperfecciones.
5. Doblar o partir. El código va a evolucionar sí o sí, así que es mejor si aprendes algunas técnicas que permitan mantenerlo y modificarlo fácilmente.
6. Mientras escribes código. Consejos a tener en cuenta mientas estás escribiendo el código. En mi opinión, se trata de otro gran capítulo del libro que combina conocimientos teóricos (por ejemplo, cómo estimar el coste de un algoritmo) con recomendaciones muy prácticas (por ejemplo, como refactorizar código).
7. Antes del proyecto. Si eres de esos programadores a los que les encanta ponerse a programar en seguida, este capítulo es de obligada lectura. Te explica cómo obtener los requisitos del proyecto y te advierte de los diferentes problemas que puedes (y vas a) encontrarte.
8. Proyectos pragmáticos. Es el último capítulo del libro y, como tal, viene a resumir todos los puntos que se han tratado en los anteriores. En él se hace especial hincapié en el equipo, los automatismos, el testing…

Finalmente, comentarte que el libro incluye unos 40 ejercicios con sus respuestas. Aunque no es necesario hacerlos, es una buena forma de poner a prueba si has entendido lo que te explican y de reflexionar un poco más sobre lo que has leído. Además, las respuestas están también muy bien explicadas, con lo que no te será difícil afianzar conceptos.

Los 3 mejores consejos del libro

Tal y como te acabo de comentar, el libro esta lleno de consejos que te ayudarán a llevar tus proyectos a buen puerto. Aunque todos ellos son recomendables por un motivo u otro, siempre me gusta mojarme y compartir los tres puntos que, en mi opinión, son más útiles. ¡Así pues, vamos a por el podio de consejos!

Nelio A/B Testing

Me sorprendió mucho la calidad del plugin, lo fácil que fue configurarlo y el increíble soporte que me dio Nelio. Recomiendo encarecidamente usar Nelio A/B Testing.

Josette Millar

WordPress.org

Ver planes

? Bronce. «Los males de la duplicación».

Este consejo ya lo he avanzado unos párrafos más arriba, así que no era difícil imaginar que sería uno de mis favoritos. El libro habla con muchísimo detalle sobre los problemas que supone tener código y/o conocimiento duplicado. Una de las cosas que más me ha sorprendido (y que le ha hecho merecedor de este bronce) es la explicación de porqué aparecen duplicidades.

Según Hunt y Thomas, la mayoría de las duplicidades que vemos corresponden a una de las siguientes categorías:

• Duplicidad impuesta. Los desarrolladores sienten que no hay otra; el entorno les obliga. Por ejemplo, «tenemos que comentar el código», con lo que el código y los comentarios acaban describiendo el mismo conocimiento (y, por lo tanto, lo estamos duplicando). O necesitamos una clase que represente una entrada de la base de datos, con lo que sus atributos y las columnas de la base de datos son, de nuevo, una duplicidad.
• Duplicidad inadvertida. Los desarrolladores no se dan cuenta de que están duplicando información. El ejemplo que ponen lo explica muy bien: tienes una clase Línea con los atributos inicio, fin y longitud. Pues bien, el atributo longitud es una duplicidad, puesto que se puede calcular a partir de inicio y fin.
• Duplicidad impaciente. A los desarrolladores les entra la pereza y duplican cosas «porque es más fácil». ¿Necesitas una función parecida a otra que ya has escrito, pero con un pequeñísimo cambio? Duplícala y aplica ese cambio.
• Duplicidad inter-desarrolladores. Cuando tienes a varios miembros trabajando en un mismo proyecto, es posible que varios acaben escribiendo «lo mismo» (aunque no «igual»). De nuevo, estaríamos duplicando conocimiento.

? Plata. «Sólo es una vista».

Una de las primeras cosas que seguramente has aprendido es no escribir un programa como un único bloque, sino que debes partirlo en pequeños componentes/módulos, cada uno con sus responsabilidades (lo que se llama «divide and conquer«). Luego, cuando el programa se pone en marcha, ya todo es cuestión de conseguir «sincronizar» esos módulos, que hablen entre ellos para solucionar tu problema. Pues bien, en este consejo del libro (en el capítulo 5) los autores te presentan el concepto de «eventos» y el patrón «Modelo-Vista-Controlador» para orquestar esa «sincronización».

Al tratarse de dos paradigmas muy utilizados en el mundo web, especialmente con la aparición de frameworks como Backbone, React o Angular, está claro que este consejo se merecía la plata de mi lista. A través de los principios de «publicación» y «suscripción», los eventos te permitirán reducir el acoplamiento entre componentes. En esencia, un componente puede suscribirse a los eventos que otro componente publica. Esto permite que cada componente escuche aquello que le interesa (suscripción) mientras que lo mantiene desconectado totalmente de aquellos componentes que se interesan por él (publicación).

Una arquitectura montada con eventos permite la implementación del patrón modelo-vista-controlador. La vista siempre escucha al modelo para que, cuando se produzcan cambios en él, ésta pueda mostrarlos al usuario. Por otro lado, la vista también escucha las interacciones del usuario para actualizar el modelo de forma pertinente.

? Oro. «Código que sea fácil de probar» y «Testing despiadado».

Finalmente, llegamos al oro de mi selección de hoy: el testing. No siempre es fácil encontrar el tiempo o las ganas para testear nuestro código, pero, como ya te he dicho otras veces, es importantísimo que lo hagas. Y los autores del libro coinciden con mi visión.

En el capítulo 6 hablan sobre la importancia de escribir código que se pueda testear. Esto ya lo hemos tratado en este blog, pero básicamente consiste en escribir pequeñas unidades de código con una funcionalidad muy bien definida en forma de entradas y salidas. Si cumplimos estas premisas, seremos capaces de escribir tests unitarios que nos permitirán verificar el correcto funcionamiento de nuestros componentes. También es importante crear una cultura del test, de tal forma que todos los miembros de tu equipo se sumen a ella y vean la utilidad del testing.

En el capítulo 8 los autores vuelven a subrayar la importancia del testing. Aunque podría entretenerme en resumir lo que allí explican, creo que la siguiente frase lo dice casi todo:

La mayoría de los desarrolladores odia el testing. (…) Los programadores pragmáticos somos diferentes. Queremos encontrar nuestros bugs ahora y así ahorrarnos la vergüenza de que sean otros quienes los encuentren después.

¿Aún no te ha quedado claro? El siguiente consejo (Tip 62 del libro) pone la guinda:

Realiza tests pronto. Realízalos a menudo. Hazlos automáticamente.

Aplicándolo a WordPress

El programador pragmático no es un libro que esté pensado para desarrolladores WordPress en particular… pero la mayoría de consejos que incluye se pueden aplicar más o menos de forma directa en el contexto WordPress. De hecho, mis tres consejos favoritos describen problemas que aparecen sí o sí en WordPress.

Un buen programador no es aquel que escribe el mejor código, sino el que tiene una visión más global de todo el proyecto. Tal y como hemos estado viendo en la entrada de hoy, es aquel que no se repite, que se pone en la piel del usuario, que evita problemas, que escribe buena documentación, que prueba su código… Sinceramente, no creo que sea necesario justificar la utilidad del libro en el contexto de WordPress, porque creo que los ejemplos que te he puesto hablan por sí solos. Así que, sí: mi recomendación es que lo tengas en tu estantería, lo leas con cariño y lo consultes de vez en cuando ?

Imagen destacada de la portada del libro «The Pragmatic Programmer: from journeyman to master«.