[007] La biblia del programador

Introducción

20 años en el mundo de la programación dan para mucho. He visto pasar ante mi muchas tecnologías y algunos paradigmas de la programación. He leído a los mejores programadores y me he nutrido de sus experiencias haciéndolas mías.

¿ Qué es para mi la programación ?

Si fuese un programa podría contestar fácilmente a esta pregunta y diría que la programación es una ciencia, pero como soy un ser humano la contestación se complica. Si programar se entendiese solamente como darle instrucciones a un ordenador, sería algo que haría todo el mundo. Mi definición de la programación sería las siguiente:

" Disciplina de ingeniería que con habilidad crea arte."

La escritura de código de programación hay que verla con ojos de autor, tal cual un escritor literario que con sus letras crea algo que toma vida propia. Por ello la literatura y la programación son mucho más que el simple acto de escribir. Ha de convertirse en una experiencia religiosa.

En la parte de oficio que tiene la programación, es puro bricolaje y como tal necesita herramientas. Es el único trabajo que permite a la par ser ingeniero y artista.

¿ y Qué es un programa ?

Un programa es un mecano de piezas que para unirlas son necesarias diversas cualidades, y que una vez unidas se crea un bello objeto matemático de técnica, ingeniería y arte. Si queremos ver un programa como algo físico podemos compararlos con cualquier aparato mecánico. El interior de un programa es muy parecido a como en una máquina una rueda dentada engrana con otra. Está lleno de simetrías.

Un programa es algo muy hermoso cuando sus usuarios no han necesitado casi formación para manejarlo volviéndose extremadamente coherente, cuando es claro y limpio... cuando está bien estructurado. Tan hermoso como para imprimirlo en papel de pergamino y llenar una pared con él.

"El mejor programa es aquel que sea tan fácil de entender como un electrodoméstico."

Esto quiere decir que el programador ha puesto toda la complejidad de su parte. Nadie necesita un curso intensivo de formación para usar una lavadora. Es algo comprensible a la par que elegante.

¿ Cómo es un mal programa ?

• Es aquel que limita o no permite añadir fácilmente características una vez terminado. 
• Es aquel que se convierte en algo extremadamente complejo para el usuario. 
• Es aquel que no tiene una base sólida que podría ser utilizada como un framework de trabajo para posteriores proyectos. 
• Es aquel que tiene muchas dependencias de productos de terceros, dejando de ser una creación propia. 
• Es aquel que tiene tantas imágenes que la suma del peso de las mismas es más del doble que el peso del código del propio programa. 
• Es aquel que consume excesivos recursos obligando a los usuarios a tener computadoras potentes.
• ES aquel que no podamos clasificarlo como minimalista.

Lo primero de todo...

El primer paso para empezar a programar es imaginar, sin escribir ni una línea de código. Hay que tomar una pluma, un lápiz o una estilográfica y comenzar a plasmar esa idea en un papel, dibujar, dibujar y dibujar. Para ello podemos utilizar UML o nuestros própios garabatos, incluso realizar un "Metaprograma". Una vez definida la estructura principal de nuestra creación podemos iniciar el proceso escribiendo código. Esta parte junto con las interfaces gráficas es el arte que mencionaba anteriormente. En una segunda parte el conocimiento y la aplicación de los mejores algoritmos es la ciencia.

El código debe ser terso y conciso. Tenemos que ser capaces de explicar cualquier algoritmo de nuestro programa en una sola frase. Para ello los algoritmos no deben ocupar más de una página.

Las características  que todo buen programa debe tener son:

• GRANULARIDAD: Para que nos entendamos lo diré con otra palabra "Flexibilidad".
• SIMPLICIDAD: Fracionar el programa en piezas separadas.
• HOMOGENEIDAD: Evitar las excepciones o casos especiales dentro de los programas.
• RECURRENCIA: Optimización, Optimización y más Optimización.
• TRANSPARENCIA:  Los usuarios deben olvidar que hay un programa entre ellos y los datos.

Mis Herramientas son...

La primera herramienta que debe dominar un buen programador son las matemáticas, debe tener una bases sólidas, las cuales nos ayudarán a razonar y nos permitirán a través de la abstracción ver más allá de nuestros ojos. Otra herramienta muy importante para no perder las conexiones con el mundo real son seguimiento de las humanidades. 

"No podremos crear nunca un buen programa de contabilidad si no la entendemos."

El código de terceros es una herramienta vital en nuestros inicios, y yo diría que siempre. Nos permite aprender que es lo que debemos y no debemos hacer para dominar un lenguaje de programación, además nos proporciona un punto de vista nuevo desde el que contemplar nuestro trabajo. 

El inglés técnico es una herramienta vital para mi trabajo como programador. Aunque suene raro otra de mis herramientas se basa en rodearme de gente con mucho talento. El buen programador conoce tan bien sus herramientas como el pintor sus pinceles. El dominio de las herramientas de programación, y no me refiero sólo al IDE, permite crear la herramienta principal que son nuestros programas.

Como no fiarse de uno mismo...

Es sumamente importante que realicemos frecuentes revisiones de nuestro código. Los mejores programas son aquellos que se han realizado por una sola persona. Los programa realmente buenos, es decir las obras de arte, viven para siempre y nunca dejarán de escribirse.

Los tiempos son importantes, hay que controlarlos. En la mayoría de los proyectos el último 10% consume el 50% del tiempo.

Nunca hay que dejar de optimizar, optimizar y seguir optimizando. Nos saldrán piedras en el camino pero cuando desarrollemos un programa, se nos abrirán puertas y pasajes inesperados.

Lo que hay que tener...

Para ser un buen programador se necesita una combinación de talento, temperamento, motivación y trabajo intenso. Esto no es una profesión es un dogma de fe y son necesarios altos niveles de vocación para destacar. El riesgo más importante es aquel que pueda hacer perder el contacto con la realidad.

Un buen diseño implica adquirir con tu programa y con sus usuarios una serie de compromisos y equilibrios, y esta es la parte más compleja. Es importante no enamorarse con locura de una idea, ( los placeres sensuales llevados al exceso son una maldición más que una bendición ), cuidado con la adicción, ya que si lo hacemos estaremos destinados al fracaso, pues como hemos mencionado desconectaremos al programa de sus usuarios. 

"Hay que hacer que funcione en un tiempo razonable, y luego ser capaz de deshacerse de ello."

Los ciclos de programación han de ser rápidos en su edición, ejecución y depuración continua. Tiene que convertirse en algo divertido sentarse frente al portátil y dejar que fluya el código. No debe ser necesario tener que implementar en nuestros programas ingentes cantidades de comentarios, el programa en sí tiene que ser capaz de explicarnos lo que hace, para que sirve.

Hay que tener la capacidad, yo diría que la humildad, de no dar nunca por supuesto que uno sabe algo que otro no sabe. Ser un gran aprendiz de todos, antes que un gran oficial de algo. Debemos aprender a poner en duda nuestras propias suposiciones. Debemos tener un buen sentido estético con una aguda conciencia para infringirlo, mezclado con un poco de complejo de culpa que nos obligue a mejorar continuamente.

Un buen profesional será aquel que sea capaz de leer unas 25 páginas de código y comprenderlas en un tiempo razonable. Esto lo hará ser práctico, que no inteligente. He conocido a mucha gente inteligente que no es práctica.

El afán de absorberlo todo, libros, código de otros programadores, etc. ha de ser interminable. Aunque la creatividad sea un Don, también se puede aprender mucho de la creatividad de los demás. No hay que tener miedo en programar tantos proyectos distintos como se nos presenten. Si uno tiene interés, necesitará sólo una parte del talento necesario para crear algo coherente y de calidad.

Una de las mejores cualidades de un buen programador es aquella que le hacer llegar siempre al fondo de las cosas, abriéndose paso a paso entre los amasijos de código para descender al los niveles más fundamentales para resolver cualquier fallo de diseño.

Los trucos de la veteranía...

Para controlar la complejidad de nuestros proyectos debemos dividirlos en partes más pequeñas. Tenemos que descomponerlos en fragmentos manejables y simples. Empezaremos por resolver los fragmentos más difíciles. Esto mismo nos servirá para manejarse en la vida y arreglárselas bastante bien. Lo más importante es definir de la forma más precisa los interfaces entre nuestro sistema y el mundo real. 

El truco esta en definir los algoritmos de manera que los podamos tener completamente almacenados en nuestra cabeza. Como he mencionado tenemos que desarrollar la cualidad que nos permita organizar la idea en la que se basa nuestro proyecto en una estructura más simple y manejable, especificando cada componente. 

"No hay que comprometerse demasiado pronto, ni adelantar decisiones sino es necesario."

 Mi consejo es no meterse en desarrollos de varios años sin resultado alguno en el corto plazo, no más de un trimestre, para poder así evaluar, reagrupar y tener la posibilidad, si es necesario, de empezar de nuevo. No hay que dejar de construir programas rápidos y pequeños que usen algoritmos claros y concisos, es necesario para la salud mental de cualquier programador.

La resolución de los problemas de un proyecto nunca es algo que se me ocurre, siempre es algo que simplemente ocurre. 

"Siempre habrá una gran diferencia entre lo que nos gustaría hacer y lo posible."

Si trabajamos en equipo el ambiente para el intercambio de ideas ha de ser abierto. No hay que guardarse nada. En la transmisión de conocimientos está la estabilidad profesional y la sabiduría. Tenemos que tener nuestro propio estilo.

Hay que tratar siempre de aislar los algoritmos que son utilizados en diferentes procesos, para economizar en el código y mejorar así la velocidad. 

Hay que hacerse siempre las mismas preguntas: ¿ Que Quiere realmente el usuario ?, ¿ Que van a usar realmente de lo que quieren ?, ¿ En que les va a beneficiar ?, los usuarios siempre van ha hacer las cosas de manera diferente a como las ha implementado el programador.

Hasta que realmente se valida un programa por parte de los usuarios, trabajando con él durante algún tiempo, no se pueden ver sus puntos débiles.

La clave para el oficio de programar estriba en encontrar y aplicar las reglas que configuran el núcleo de nuestro aplicativo. Hay que tener conciencia de ello. 

"Los mejores programas proceden directamente del planeta de la intuición."

La materia prima...

La materia prima de un programa y su recurso más valioso son los datos, la información. Y no solo me refiero a la información que acabarán introduciendo los usuarios, sino aquella información interna (variables, tablas de decisión, ficheros de configuración, etc.) que se convertirá en el flujo de la vida del mismo.

El código en sí, también puede ser denominado como materia prima, pero deja de serlo una vez lo hemos plasmado en nuestro programa.

El éxito...

Bueno, supongo que el éxito debe ser algo así como hacer el programa adecuado en el lugar adecuado y en el momento oportuno. Por otro parte el éxito en el trabajo está en hacer la misma cosa una y otra vez, para ir aprendiendo cada vez un poquito más y así hacerlo cada vez un poquito mejor.

Tenemos que pensar que las buenas ideas no vienen fácilmente, por ello hay que rodearse de gente que sea mejor que tu. Más que cualquier otra cosa lo que nos tiene que motivar es el deseo de que nuestros programas sean usados por tanta gente como sea posible.

Si fracasamos en algún proyecto y nos hace caer, sólo nos queda para llegar a tener éxito una opción... Levantarse y volver a empezar.