Llevo aprendiendo lenguajes de programación desde que tenía 12 años. A esa edad aprendí Basic, del cual muchos de vosotros os acordaréis. Me tiré mucho tiempo aprendiendo y profundizando en ese lenguaje procedural, el cual me introdujo en todo este mundo . Un tiempo más tarde, avance a QuickBasic con más estructuras de control y mejor entorno de desarrollo.

A partir de ahí empecé a interesarme por Pascal, con el cual aprendí a estructurar bien el código, o todo lo bien que creía en ese momento. Y con Turbo Pascal aprendí los principios de la programación orientada a objetos.

Con 16 años y recién salido del instituto sabía que lo que quería hacer para ganarme la vida era programar, aprender más lenguajes y perfeccionar lo máximo su técnica.

 

 

A esa edad ya estudiando, aprendí en una asignatura C, con su control de memoria, sus librerías, toda esa potencia y su control de bajo nivel. Con este lenguaje empecé a sentirme “poderoso” y a tocar cosas que realmente alteraban el sistema. Aprendí más profundamente en que consistían las fases de compilado y linkado. También empecé a preocuparme por el aspecto de mi código. Con el que yo me sentía muy cómodo. Pero después de volver a mirar hoy las lineas sacadas del baúl de los recuerdos, he visto que me quedaba muchísimo por aprender :S

Ese mismo verano, junto con mi hermano, empecé a vislumbrar los lenguajes de Microsoft con los que era sencillísimo crear las interfaces gráficas de usuario y C++Builder nos sirvió para eso mismo. Lo afiancé con una asignatura al año siguiente sobre Visual Basic. Con el que aprendí el paradigma de programación dirigida por eventos.

Una vez trabajando en mi primera empresa, tuve que vérmelas con FORTRAN, aunque por suerte no demasiado tiempo De Fortran pasé a estar varios años desarrollando en Tcl/Tk. Un lenguaje ahora en desuso, pero que sigue viniendo por defecto instalado en multitud de distribuciones de Linux.

Con Tcl vi la fuerza de los lenguajes interpretados, su facilidad de uso y sobre todo su potencia en sentencias sencillisimas que no tienen nada que envidiar en la velocidad de ejecución de los programas en C. De hecho, me hice hasta un programa de benchmarking para comparar la rapidez de ejecución entre Tcl y C.

Con este lenguaje llegué a mi mejor nivel de maestría hasta el momento, me conocía toda la sintaxis y sus combinaciones a la perfección. Podía desarrollar cualquier cosa en poquísimo tiempo y me sentía agustísimo utilizándolo. De hecho, hasta colaboré en el proyecto a’MSN construido en este lenguaje.

 

 

En esta época me apunté a estudiar en la UNED y en otra asignatura aprendí Modula2. Del cual solo tengo que decir, que no está bien ni para empezar a aprender orientación a objetos, ya que no tiene herencia de ningún tipo.

Después cambie de división y proyecto dentro de la empresa, y entré en el verdadero mundo de los equipos de desarrollo. Un proyecto de 5 años en un equipo de casi 40 desarrolladores escrito en C++ sobre Linux. En esta época fue cuando más avancé en conocimientos sobre programación. Gracias sobre todo a los compañeros con más experiencia que me iban enseñando paso a paso patrones de desarrollo, control de punteros en profundidad, herencia multiple, a trabajar con ramas en repositorios de código que utilizaba todo el equipo, etc etc… Y lo más importante de todo, a ver mi trabajo desde el punto de vista de un profesional que quiere hacer todo lo mejor que puede su trabajo.

De ahí cambié de empresa y empecé a trabajar con Java. Simplificándome mucho las cosas al venir de C++. Sin control de memoria, sin punteros, independiente de plataforma y con soporte para red diréctamente. Aunque como no, con muchas taras de fábrica, como el no ser absolutamente orientado a objetos o no poder sobrecargar operadores.

También al principio en esta empresa, me toco mantener un programa desarrollado por otra, hecho en Flash con ActionScript. Este semi-injerto de lenguaje de programación lo sufrí más que degustarlo. Con sus MovieClips y su caótico interfaz en el que tienes que declarar cada objeto en tres sitios diferentes.

He tenido múltiples encontronazos fugaces con otros lenguajes como PHP, Bash (si lo podemos definir como lenguaje), Ruby, JavaScript, C# y esta misma semana Clojure, pero con los que solo he aprendido partes de su sintaxis y no he llegado a hacer nada serio.

 

 

Ahora mismo estoy inmerso en el aprendizaje de Groovy, un lenguaje bastante moderno, basado en Java, muy fácil de aprender, pero muy potente y productivo. Con el que pretendo desarrollar una web que seguramente comente en este blog más adelante. Aunque también estoy apunto de empezar en un grupo de trabajo para leer y aprender con “Seven Languages in Seven weeks” que retrasará mi enseñanza de Groovy seguramente.

En resumen, cada vez que miro atrás y observo mi código de hace algún tiempo, me doy cuenta de que si he avanzado. Veo cosas escritas por mí que ahora nunca permitiría subir al repositorio, código duplicado sencillísimo de refactorizar y este tipo de cosas. Pero ver justamente estos fallos es muy bueno. Me alegro de comprobar que no me he quedado estancado y he aprendido poco a poco como se deben hacer las cosas. Se que aún me queda muchísimo por aprender y practicar, pero sentir ese avance me da más ganas de continuar con ello.

Así que os aconsejo que de vez en cuando vayáis guardando algún trozo de código del que os sintáis orgullosos. Hacedlo cada cierto tiempo, 6 meses, 3, un año, es igual. Pero eso sí, cada año al menos, cuando sintáis un cambio en vuestra vida, cuando estéis decaídos por que creéis que no habéis hecho nada en años, o os apetezca simplemente, mirad ese código y podréis observar si al menos en esto habéis aprendido algo.

La mayoría de gente con la que he trabajado programando, cuando tenían que hacer alguna aplicación, una parte, API, clase o lo que fuera, lo escribían y ya está. Incluso yo hasta hace no mucho tiempo, escribía el código que mejor me salía a la primera y ahí lo dejaba, a veces orgulloso de él y todo :S . Por suerte, después de unos años de experiencia he aprendido que esto no debe ser así. 

No nos deberíamos limitar a  escribir un programa de principio a fin a la primera. Más importante aún, no deberíamos esperar ser capaces de escribir programas limpios y elegantes a la primera. Si algo he aprendido durante todo el periplo que ha supuesto mi carrera estudiantil y profesional, es que la programación es un arte más que una ciencia. Para escribir un código limpio, primero debemos escribir código sucio y luego limpiarlo.

Esto no debería ser una sorpresa para nadie. Escribir código limpio, es una cuestión de refinamientos sucesivos. Primero debemos escribir una primera versión, después revisarla, corregir lo que creamos conveniente, a continuación, volver a revisar y volver a refinar, y así sucesivas veces. Tener un ciclo de refactorizaciones sucesivas.

Un símil muy bueno se puede hacer con los polinomios de álgebra, donde los descomponemos en factores y los factorizamos paso a paso para hacerlos más simples y comprensibles sin modificar su resultado para llegar a una solución. Bien, pues con el código debemos hacer lo mismo, llegar a una solución lo más comprensible y simple para todo el mundo que vaya a meter mano a ese código.

La mayoría de los programadores jóvenes (con pocos años de experiencia en este tema) no están de acuerdo con esta técnica y no sigue este consejo muy bien. Ellos creen que el objetivo principal es conseguir que el programa funcione, dando igual como esté escrito por dentro. Terminando así con un código ilegible, código espagueti, o como le queráis llamar. Solo preocupa que funcione lo requerido y poder pasar así rápidamente a la siguiente tarea. Parafraseando a Uncle Bob “Los programadores más experimentados saben que esto es un suicidio profesional”.

El principal problema de que un programador se acostumbre a hacer refactorizaciones sucesivas de su código y cuidarlo con mucho más mimo, es que supone un esfuerzo y este esfuerzo no se ve plasmado en funcionalidades para el proyecto. A pesar de ello, si utilizamos esta forma de programar refactorizando, como técnica de desarrollo a lo largo del proyecto, conseguiremos que nuestro código sea de calidad y mucho más legible, ya no solo para nosotros, sino también para el resto de programadores del equipo. La experiencia dice (y no solo la mía) que este tiempo empleado en cada refinamiento sucesivo, será recuperado repercutiendo con creces en el avance del proyecto en el futuro.