El arte de programar

Cuando empecé con el sinclair zx81 a programar en mi casa, mi principal objetivo era aprender el lenguaje de programación, el basic, que me ofrecía dicho ordenador.

Mientras seguía programando por afición, simplemente hacía código. Quería un programa que hiciera algo, normalmente un juego, lo programaba lo más rápido que podía y lo depuraba hasta que funcionaba. La elegancia del código, su reusabilidad o cualquier otra consideración de este tipo era algo que ni siquiera sabía que existía. Usaba los "goto" y las variables globales sin ningún tipo de remoridimiento<, sin saber que eso era "pecado".

Al empezar a trabajar como programador, el objetivo inicial era el mismo. El jefe me mandaba algún programa para hacer, esta vez no era un juego, y lo hacía lo más rápido posible hasta que funcionaba. Por aquello de cumplir con cierto formalismo, usaba menos las variables globales, no usaba el goto y procuraba comentar algo el código. Era cosas que había oido que eran buenas, aunque no sabía muy bien por qué.

Con el paso de los años, trabajando de programador, empezaba a hervirme la sangre al ver que tenía que repetir el mismo código o muy parecido una y otra vez. Al ver que mis compañeros repetían código que yo ya había hecho y que no les servía porque no estaba suficientemente aislado. Al ver que los compañeros tenían código que yo necesitaba pero no podía utilizar por los mismos motivos.

Todo esto me llevó a plantearme hacer el código de forma distinta. Cada vez que veía que algún trozo de código se repetía una y otra vez, trataba de buscar la forma de que ese código fuera único, de hacerlo una única vez para que sirviera en cualqueir sitio. En este tiempo fue cuando llegué a darme cuenta de lo que realmente era y da las infinitas posibilidades que ofrecía la programación orientada a objetos. Una cosa era hacer clases y heredar de vez en cuando como hacía antes y otra la nueva forma de hacer código que estaba descubriendo.

Al descubrir todo esto, emepecé a investigar por internet las formas de hacer ese código reutilizable, de cómo usar la orientación a objetos. Tropecé entonces con todo el tema de patrones de diseño.

Me llamó muchísimo la atención que después de varios años programando en el trabajo, estaba llegando muy despacio, sin saberlo, a una versión primitiva de los patrones de diseño. Muchas de las soluciones que iba encontrando con mucho esfuerzo, a base de ensayo y error, eran los patrones de diseño. Me estaba costando varios años llegar a una versión primitiva de los patrones de diseño, a reinventar la rueda.

Actualmente, creo que programo con un poco más de conocimiento de causa. Cuando quiero hacer algo, no tengo que inventar cómo, conozco bastantes patrones y los aplico cuando lo creo necesario. Sin embargo, sigue sin gustarme totalmente el código que hago.

Asi que de alguna manera, cuando necesito tocar código ya hecho y que no me gusta, trato de arreglarlo. Es curioso, pero veo en internet que eso también está inventado. Lo llaman refactorización y es algo a lo que también llegas, si no lo lees antes, después de varios años de hacer código.

Después de quince años programando en el trabajo ocho horas diarias (es un decir, algún que otro día estoy vaguete y hago otras cosas), todavía descubro cosas, veo que no sé programar lo suficientemente bien. No quiero decir que mis programas no funcionen, eso ya está superado hace tiempo, simplemente quiero decir que cuando más adelante necesito ese código para otra cosa, nunca está cien por cien disponible, siempre hay que tocarlo algo. También veo, en internet, que los grandes gurús de la programación comentan que tienen el mismo problema, aunque programan cien veces mejor que yo. No hacen bien el código a la primera y por eso cada vez desisten más de hacer el diseño óptimo a la primera y necesitan cosas como la refactorización. El código, por mucho que se piense y bien que se haga, siempre necesita ser retocado para reutilzarlo. Con esto quiero decir que un programador, por muy experimentado que sea, siempre encuentra formas de mejorar y nunca hace el código óptimo a la primera.

Sin embargo, existe una diferencia abismal en la rapidez y calidad del código generado por un programador exerto con varios años de experiencia y que se preocupa por todas estas cosas con respecto al programador novato. Un programador experto con su propia librería de componentes reutilizables puede hacer un proyecto en un tiempo muy inferior al de un programador novato que reutilice el proyecto anterior. Además, el código reutilizado por el experto da muchos menos problemas y está muy depurado.

Todo esto me lleva a sentir pena por las empresas actuales de software. Puede que haya excepciones, pero actualmente la programación es una cosa que las empresas no aprecian. Suponene que bastan unos meses de práctica para saber programar perfectamente. Se han quedado en que un buen programador es el que hace un programa que funciona en un tiempo razonable, es decir, lo acaba un par de meses después de que se acabe el plazo de entrega. ¡Sólo dos meses de retraso! ¡Qué maravilla!.

Es normal que las empresas de software contraten a un universitario o fp recién salido, que puede ser más o menos hábil en programar y le pongan a hacer un programa. Por supuesto, nadie le cuenta que existen los patrones de diseño ni la refactorización ni le dicen, por supuesto, que dentro de un año tiene que hacer otro programa muy similar, pero distinto y tenddrá que retocar su código si no lo hace bien ahora. Esta persona, cuando lleva un tiempo, la echan o se va porque está subcontratada o le dan algún cargo de responsabilidad y le hacen jefe de algo. El caso es que deja de programar en esa empresa. Es normal que ninguna persona se tire varios años programando (yo soy una excepción, porque soy especialmente asocial y no me "ascenderán" ni a tiros).

El resultado es que el software de muchas empresas puede más o menos funcionar correctamente, pero no es todo lo reutilizable, ampliable y modificable que debiera. Un nuevo desarrollo de software por parte de esa empresa, requiere casi recodificar todo desde cero o copiar, pegar y modificar el proyecto anterior, gastando mucho tiempo en depuración. Además, es normal que esta tarea de copia, pega y modifica la haga un nuevo contratado que sustituye al que hizo el código original. En fin, que el código de muchas empresas siempre está hecho por gente "novata" y retocado por gente "novata".

Si hubiera programadores experimentados, que realmente les gusta hacer el código reutilizable y bien hecho y se les diera tiempo para ello y otro montón de cosas "imposibles", los proyectos de las empresas, una vez saltado el bache de empezar, saldrían mucho más rápido y con mucha más calidad. Se utilizaría tal cual mucho código hecho y depurado en proyectos anteriores, sin necesidad si quiera de recompilarlo. La empresa, en unos años, tendría sus propias librerías específicas para el tipo de proyectos que hace.

En fin, una pena.