Me sorprende a menudo cómo los desarrolladores de software nos complicamos la vida por no dar un paso atrás e identificar aquello que nos impide centrarnos en escribir código de producción y testearlo. Los problemas casi siempre surgen de no montar en entorno adecuado de pruebas que permita testear la nueva funcionalidad que incorporamos con comodidad. El extremo más radical de esto consiste cuando la única posibilidad de probar algo es ¡en el entorno de producción del cliente!. Me temo que sólo mecionarlo se me pone la piel de gallina, aunque lamentablemente lo he vivido y lo he visto en varias ocasiones.

Cuando comienzo un nuevo proyecto, aunque sea sencillamente probar una tecnología que desconozco y con la que comienzo a jugar, lo primero que hago es montar un entorno en el que trabajar con absoluta comodidad: si no lo hacemos así, a los problemas habituales de resolver errores y avanzar en aquello que no conocemos bien le añadiremos los inconvenientes de trabajar con ese entorno incómodo (o lo que es lo mismo, perderemos más tiempo en problemas con el entorno que en crear software útil).

Por poner un ejemplo, últimamente estoy haciendo algunas pruebas de concepto implementando algunos módulos en node.js que acceden a un servidor MongoDB. Lo primero que he hecho ha sido instanciar una máquina virtual con un Ubuntu Server en el que arrancar MongoDB; una vez que aprendo a limpiar completamente todas sus colecciones y realizar las tareas de administración básicas y suficientes para las pruebas que quiero implementar, todo lo demás lo puedo realizar mucho más rápidamente y cómodamente y, sobre todo, en pocos pasos.

Esto parece una trivialidad, pero si no lo hacemos así y estas operaciones elementales no las hiciera con sencillez, me resultaría muy complicado avanzar en las pruebas de node.js que estoy realizando: terminaría hastiado y acabaría abandonando más pronto que tarde.

El pricipio que me encanta aplicar en esto es aquel que indica que para las tareas repetitivas, sólo deberíamos trabajar una vez.

Efectivamente, sólo dedico algo de tiempo al comienzo para crearme un entorno de trabajo lo suficientemente cómodo como para poder centrarme en las pruebas o lo más importante del trabajo que me propongo realizar.

No hace mucho terminé de leer un libro que me ha encantado; se trata de El Efecto Compuesto de Darren Hardy (se puede encargar en español aquí), sobre cómo los pequeños hábitos y las pequeñas acciones, mantenidas en el tiempo y con constancia, representan realmente una gran diferencia.

Del mismo modo, ¿como sería nuestro trabajo si cada vez que quisiera ejecutar la prueba X necesitara pasar cinco minutos limpiando una base de datos, levantar ciertos servicios, etc.?, ¿cuánto tiempo perderíamos al usar un editor que no dominamos del todo?, ¿cuánto tiempo perdido si tuviéramos que probar algo leyendo el resultado en un documento txt?.Para ser productivos escribiendo el código de producción en el que trabajamos tenemos que crearnos entornos sencillos y eficientes, lo que requerirá seguramente dedicar algo de tiempo la primera vez que se genera ese entorno, aunque esa pequeña inversión de trabajo y tiempo la rentabilizaremos con creces posteriormente.

De nuevo, vemos cómo un buen y profesional desarrollador de software, competente en su ámbito, con suficiente experiencia, no llegaría al 10 si no se rodea de hábitos y condiciones que permiten que su trabajo se haga con comodidad y eficiencia.

Comparte esta entrada...

¿Por qué leer El Libro Negro del Programador?

Adquirir desde:
Amazon (kindle eBook / papel)
CreateSpace (papel)
PayHip (epub / mobi / pdf)

El libro negro del programador.com
Segunda Edición - 2017

Archivo

Trabajo en...