The Pragmatic Programmer

Ya he terminado de leer "The Pragmatic Programmer", compañero inseparable en las terrazas de verano de todo "nerd" que se precie.

Para mi gusto se queda demasiado en la superficie y simplemente cuenta cosas que más o menos todos sabemos, pero no aplicamos.

Sin embargo, siempre es bueno ver por escrito todo esto que sabemos y no hacemos, que nos recuerden de vez en cuando las ventajas que tiene y, desde luego, ayuda mucho a aclarar ideas. También da ideas nuevas, cosas que supongo que acabaríamos intuyendo con el tiempo, pero leyendo este libro caemos en la cuenta mucho antes.

Lo más importante que he sacado en claro es el principio de "no te repitas". Yo siempre he tenido claro que el código no se debe repetir, pero en el libro van mucho más allá. No se debe repetir dos veces la misma información no sólo en el código, sino tampoco en la documentación, composición de las bases de datos, etc, etc.

La idea es que si hay un documento que describe cómo son las bases de datos, se deberían poder construir las bases de datos automáticamente a partir de este documento o bien, generar automáticamente este documento a partir de la base de datos. Si además hay código que maneja esa base de datos, mucha parte de este código debería generarse automáticamente. De esta forma, bastaría, por ejemplo, tocar el documento de base de datos para que tanto la base de datos como el código se corrijan automáticamente.

Para poder conseguir esto, es muy importante hacerse scripts que a partir de, por ejemplo, la documentación, genere las sql para crear las bases de datos y el código fuente -en java por ejemplo-, para manejar esa base de datos. En el libro destacan la importancia de perl para este tipo de cosas -lenguaje de script avanzado que permite hacer fácilmente este tipo de cosas- y la importancia de hacer documentación con texto plano, que pueda ser leído o generado fácilmente por estos scripts.

Otra idea muy importante del libro, que posiblemente también sabemos todos y que por pereza no solemos hacer, es que cualquier tarea repetitiva, se debería automatizar. El compilado se debe hacer automáticamente todas las noches. Si al programar repetimos una secuencia de comandos con cierta frecuencia, deberíamos hacer una macro. Si al empezar una nueva clase java la generamos con un esqueleto concreto -comentario de cabecera, comentario de la clase, clase, atributo para usar log4j, etc, etc-, deberíamos tener un scripit o macro que lo haga automáticamente. Nuevamente, cobran importancia los lenguajes de script estilo perl.

Aquí ha salido nuevamente una idea para el trabajo. Un par de compañeros mios empezaron a hacer unos instaladores para los nuevos, de forma que les instalasen en sus PCs el java, el eclipse, el CVS, sacaran los proyectos de CVS, etc, etc, etc. Yo no le dí demasiada importancia, pero efectivamente es algo importante. Hablan de meter catorce personas nuevas y si se hace esta tarea a mano -preparles el entorno de desarrollo en el pc-, es una persona antigua que perderá el tiempo haciendo una y otra vez lo mismo. Es mejor hacer el instalador y usarlo cada vez que llegue uno nuevo. Cuando volvamos de las vacaciones les incordiaré para que terminen el instalador.

Otra idea del libro que me ha llamado la atención, aunque quizás de utilidad menos inmediata, es la necesidad de que los que somos programadores aprendamos lo más posible. Según el libro, deberíamos proponernos -y cumplir- leer una serie de libros al año, aprender un lenguaje nuevo cada año, etc, etc. Es más, para diversificar lo más posible, deberíamos elegir aquello lo más alejado posible del tema que tratamos en el trabajo. Si alguien trabaja con java, puede tratar de aprender perl, si alguien hace aplicaciones de escritorio, debería aprender a hacer aplicaciones web, etc, etc. El ver cómo se resuelven problemas en otros campos puede darte ideas de cómo resolver tus propios problemas en tu campo o simplemente ideas nuevas de cómo hacer las cosas de otra manera.

En fin, un libro interesante, con algunas ideas que no tienen desperdicio.