Mejora tu código con estos 7 sencillos pasos

Cuando comenzamos a programar, todo el mundo nos dice cómo utilizar un lenguaje. Nos enseñan Java, C++, C# y otros muchos más, pero nunca nos dicen cómo programar. Sabemos utilizar el lenguaje, pero hace falta mucha práctica y técnica para poder decir que somos buenos programadores. A lo largo de mi corta carrera (llevo unos pocos años programando) he aprendido varias cosas que me han sido de gran utilidad a la hora de llevar a la práctica un proyecto. Son varios puntos que poco a poco se te meten en la cabeza y que acabas utilizando sin darte cuenta. Esto lo he aprendido con la experiencia de distintos trabajos y con mucho leído sobre el tema.

0. A programar se aprende programando

Este punto ni siquiera va a ser el uno; va a ser el cero. A programar se aprende programando.

Nunca me cansaré de decirlo. ¡Me sobra la teoría! Cuando queremos aprender un lenguaje de programación tenemos que conocer sus principios básicos: sintaxis, estructura o declaración de variables. Esto está bien para empezar, pero no nos equivoquemos. Aprenderemos realmente a programar cuando nos peguemos con el código, cuando estemos horas y horas intentando hacer algo. ¿Quieres aprender Android? Haz una aplicación. ¿Quieres aprender a hacer una página Web? Haz una página Web.

Puede resultar obvio, pero mucha gente se pierde entre libros y documentación cuando quiere aprender a programar y se olvidan de lo más importante: programar.

1. Utiliza control de versiones

Cuando estéis realizando un proyecto y tengáis una versión que funcione, olvidaos de copiar la carpeta entera y pegarla en otro sitio como "Proyecto funcionando". ¿Qué pasa si trabajamos con otros programadores? ¿Qué pasa si se rompe nuestro disco duro? ¿Cómo vemos la evolución del proyecto o deshacemos ciertos cambios?

Utilizar control de versiones es quizá lo más importante que os pueda decir en este artículo. Grabadlo a fuego en vuestros cerebros de programadores: ¡Siempre usar control de versiones! Si no tenéis ni idea de lo que es esto, en Geeky Theory tenemos unos cuantos artículos sobre Git:

2. Prueba el código a diario

Hace tan sólo un par de semanas me pasó algo que ha hecho que tenga que incluir este punto. Resulta que estaba yo tan contento programando y viendo que el proyecto iba bien. Avanzaba según lo previsto y no había demasiados problemas que resolver. El proyecto en el que trabajo necesita leer muchos datos de ficheros que son privados, no se pueden publicar. Debido a esto, no los subo a Github porque el código está todo en abierto, es decir, subo todo el código excepto dichos archivos, que son 4 ó 5.

Un día, uno de mis compañeros lo prueba para ver si funciona todo correctamente (la demo se hacía en pocos días) y... ¡Sorpresa! No funciona. Había olvidado mandarle los archivos porque los veía en mi ordenador y todo funcionaba bien, pero en el repositorio se ignoraban. Yo ese día no estaba en la oficina. ¿Qué hubiera pasado si ese día hubiera sido el de la demostración ante el cliente? Nada bueno, ya os lo digo. Por suerte pude enviar los archivos por correo en cuestión de segundos.

Conclusión: intentad probar siempre el código en diferentes condiciones. Ordenadores de compañeros o en otro vuestro para ver si todo está funcionando correctamente.

3. Ten una base de datos de errores

Al programar un proyecto es muy importante tener una base de datos de errores, por ejemplo en un Excel. Podéis usar Google Drive si sois varios programadores y queréis tenerlo en común fácilmente. Estas bases de datos pueden ser muy simples o muy complejas, pero los campos que creo que nunca deben faltar en ellas son:

Pasos a seguir para reproducir el bug: necesitamos saber qué tiene que hacer el usuario para que salga el bug a la luz. Puede que no seas tú quien tenga que arreglarlo, así que vamos a facilitarle el trabajo al compañero con unas detalladas instrucciones.
Comportamiento esperado: cómo debería comportarse el programa en condiciones normales, es decir, cuando funcione bien.
Comportamiento actual (erróneo): qué pasa en el programa cuando da error.
Quién debe arreglarlo: programador al que se le asigna la tarea de fixear el bug.
¿Ha sido arreglado?: estado actual del error.

4. Arregla errores antes de escribir nuevo código

La tarea de arreglar errores debe ser una parte fundamental en la planificación de un proyecto. Es como una bola de nieve que cada vez se hace más y más grande. Cuando existe un bug, ya sea más o menos grave, hay que arreglarlo antes de desarrollar nada nuevo y no dejarlo para otro día porque no nos apetezca. A veces el cliente quiere que sigas avanzando en el proyecto sin importar nada, pero intenta convencerle de que hay cosas más importantes que hacer.

No mirar atrás en nuestro código puede suponer un gran problema. Parchear código para no tener que solucionar los errores de raíz es algo que no debemos hacer nunca. Primero soluciona todo y luego sigues.

5. Planifica el proyecto

En Geeky Theory os hemos contado cómo hacer un prototipado y cómo no perder el tiempo planificando un proyecto. Poco más os tengo que decir. Coged libreta y bolígrafo. Dibujad, apuntad, haced esquemas y anotad lo que tiene que hacer vuestro programa en una lista de tareas. Reuníos con el cliente y apuntad lo que os diga, poned ideas en común y tratad de alcanzar un acuerdo sobre las prioridades de las distintas características del proyecto.

No es en absoluto una pérdida de tiempo realizar la planificación de un proyecto. Si os sentáis a programar en cuanto se os ocurra la idea, ya os digo que lo más probable es que os salga mal y llegue un momento en el que no sepáis por dónde seguir.

Mediante la planificación de un proyecto con deadlines (fechas límite) seremos también capaces de distinguir las tareas y funciones más importantes que tiene que realizar nuestro programa y dejar a un lado las secundarias, que quizá se puedan implementar más adelante.

6. Compra el mejor equipamiento que puedas permitirte

Ni la cámara hace al fotógrafo, ni la raqueta al tenista, ni el ordenador al programador, pero algo ayudan. Este punto es algo (bastante) material, no tiene mucho que ver con la metodología a seguir durante el desarrollo de código, pero sí con la productividad.

No es lo mismo compilar y que tarde 1 segundo a que tarde 30 segundos. Tampoco es lo mismo programar en una pantalla de 13 pulgadas que en una de 22. Cuando comencé a programar seriamente, me hice con un monitor para extender la pantalla de mi portátil y... por favor no me lo quites que me da algo. Hacer debug de código en una pantalla con el IDE y en otra ver cómo se ejecuta. Por ejemplo, programando Javascript tengo en una pantalla el navegador con la aplicación y en la otra el debugger. Qué gustazo. Si estoy escribiendo un artículo en Geeky Theory, en una pantalla lo edito y en otra veo cómo va quedando. Así con todo. Si a eso le sumas que utilizo varios escritorios virtuales en Linux, pues apaga y vámonos. Productividad a tope.

Otros periféricos también son importantes, como el teclado o el ratón. Aquí ya no me meto porque en cuanto al teclado o uso el propio del portátil o uno externo muy básico pero que me va muy bien. El ratón es uno inalámbrico que uso bastante poco. Los atajos de teclado son tus amigos.

Si tenéis algún consejo del que todos podamos aprender, dejadlo en los comentarios. Estos son sólo algunos que se me han ido ocurriendo mientras escribía el artículo, pero como cada uno ha vivido sus propias experiencias, será algo interesante que todos las compartamos.

¡A comentar!