Realiza programación saludable

CeNuws4WQAAZ9_B

El miércoles pasado acudimos, mis compañeros de trabajo y yo, a una de las charlas organizadas por el meetup de Front-End Developer Madrid. La charla estuvo entretenida y la ronda de preguntas aportó muchísimo a la comunidad. Pasamos una tarde agradable al salir del trabajo.

Durante esta ronda de preguntas, se formaron varios debates interesantes y se llegó a hablar de montar arquitecturas mixtas con frameworks como Polymer con AngularJS, ReactJS con AngularJS (mi aportación irónica fue la de crear una aplicación con AngularJS 1.x y Angular 2, puestos a mezclar… XD). Estructuras extrañas y con las que yo no me suelo encontrar cómodo a la hora de plantear una arquitectura para mis aplicaciones.

Como está empezando a ser habitual, la charla me ha inspirado para un post del blog y me gustaría hablaros de un término que se me ocurrió el otro día, la programación saludable.

Últimamente, empezamos a obsesionarnos por encontrarnos bien física y mentalmente para poder rendir mejor en nuestro día a día (yo el primero). Para conseguir este reto, nos solemos plantear una vida sana. Una vida basada en una serie de principios que con rutina y voluntad, puede hacer que nos encontremos mejor con nosotros mismos y con nuestro entorno.

Pensándolo un poco, no es muy diferente a seguir una serie de buenas prácticas en nuestro trabajo como desarrolladores. Siempre intentamos seguir unas rutinas y por medio de la mejora continua vamos creando software que nos haga encontrarnos bien como profesionales y con nuestros compañeros de trabajo.

Es por ello que se me han ocurrido 3 símiles con la vida sana que pueden ayudarnos a crear una buena aplicación por medio de programación saludable.

1. Reducir el número de alimentos grasientos

Cuando nos plantean realizar una nueva aplicación, nuestra cara se ilumina y nuestra imaginación empieza a pensar en todos aquellos frameworks que hemos ido aprendiendo y que por el momento no habíamos tenido la oportunidad de usar en un entorno profesional.

Cada vez que aprendemos algo nuevo nos pasa lo mismo, estamos deseando llegar al trabajo al día siguiente para poner a prueba nuestros nuevos conocimientos.

Como profesionales, como gente a la que le gusta aprender, esto nos pone mucho, nos da mucho placer. Nos demuestra a nosotros mismos que sabemos mucho de nuestro sector y nos permite experimentar y aprender de forma empírica la teoría que nos han proporcionado.

De pronto, aplicaciones sencillas que podrían hacerse con pequeñas librerías, empiezan a mutar en verdaderas moles. Con el paso del tiempo, aplicaciones jóvenes que funcionaban bastante bien, empiezan a ir más lentas, cada vez tiene peores reflejos y fallan ante situaciones que antes eran impensables.

Incluso las actualizaciones de nuestras librerías y framework se hacen impensables por el número de dependencias y el acoplamiento que existe entre unas y otras, es como si aquel nuevo pantalón que ha salido al mercado no pudiese ni abrocharme de todo el peso que he ganado.

Cuando empiezo a ver aplicaciones que mezclan el uso de frameworks y me toca mantenerlas, empiezo a sudar. Mantener estas aplicaciones se hace bastante difícil debido a diferentes causas:

  • Aprender los frameworks de hoy en día, con la cantidad de funcionalidades que aportan, se suele convertir en complicado.Si, podemos llegar a controlarlo muy bien a saber que usar y no usar, pero por lo general siempre habrá un algo nuevo que estábamos haciendo mal y que se podría hacer de otra forma, un framework supone un aprendizaje constante. Es una grasa difícil de quitar de nuestra aplicación. Se encuentra tan pegada a las paredes que tenemos que tener cuidado con ella.
  • Pues imaginad que no solo contamos con un framework si no con dos. Por lo general los frameworks son muy genéricos y en cierta medida lo que se hace con uno, se puede llegar a hacer con otro ¿Cómo hacemos para que cohabiten? ¿Qué hacemos con uno y que con otro? ¿Por qué nos complicamos tanto la vida?
  • Puede darse el caso que los dos frameworks no tengan nada ver. Lo que visto por un lado puede ser bueno o un destrozo. Si un framework está diseñado para cumplir con el paradigma de la programación declarativa y otro con el de la programación imperativa ¿que guía de estilo sigo? ¿A quien le doy más prioridad? No se, a mi me decian que cuando saliera de copas, no mezclara bebidas o me podía dar un buen chungo, quizá aquí pueda ocurrir lo mismo.
  • Encima ya no tenemos que mantener un framework, si no dos (o tres, quien sabe). Eso supone realizar actualizaciones, corregir bugs del framework, aprender sintaxis, semántica, estructura y corregir las partes de la API que se encuentren obsoletas en nuevas versiones. Nos suele costar mucho una actualización a un solo framework, imaginaros con dos si encima, como cada vez es más común, las actualizaciones de los frameworks se realiza en periodos de tiempo más reducidos.

Lo que parecía una buena idea, se convierte en un caos y hace que nos volvamos esclavos de la programación rápida, la programación basura. Ahora somos unos simples mantenedores de frameworks en vez de unos desarrolladores de software, por tanto, cuidado, comamos solo las grasas necesarias.

2. No picotear entre horas

Pero bueno, quizá no nos guste mucho la grasa, con nuestro pequeño framework o incluso microframework tenemos toda la grasa necesaria para nuestro día a día y no necesitamos más. Lo que nos gusta es picotear entre horas. Y comiendo un poco de aquí, otro poco de aquello, nada grave, solo darnos esos pequeños caprichos en el bar de la esquina.

Para los desarrolladores de software ir a nuestro gestor de paquetes favorito, se ha convertido en bajar muy de a menudo al bar de la esquina. Ir a NPM Gastro Bar y buscar esas tapitas tan ricas que nos aportan esa funcionalidad extra que necesitemos. Un poco de MomentJS nos viene muy bien. Nos ayuda a quitarnos ese horror que es gestionar fechas en JavaScript. Incluso FormatJs puede ser un gran complemento de vez en cuando.

El problema viene cuando, tras largas temporadas, hemos dejado de cocinar por nosotros mismos y el bajar al bar se ha convertido en una costumbre demasiado habitual. Tenemos que tener cuidado en este punto.

Siempre nos han dicho que la reutilización de código, el no reinventar la rueda es importante para que podamos centrarnos en nuestro verdadero problema. Todo cierto. El problema viene cuando ese mensaje lo desvirtuamos y cualquier problema de programación que queramos solucionar, nuestra primera opción, sea acudir a nuestro gestor de paquetes favorito.

¿Por qué? Porque se puede dar un caso tan preocupante como el de leftPad. Incluir una dependencia en nuestro sistema de una microlibrería puede no ser preocupante hasta que sin darnos cuenta contamos con 50 dependencias. Dependencias que a su vez contarán con otras dependencias de las cuales tú también serás responsable si tu aplicación se encuentra muy acoplada y existe algún problema externo a ti.

Esto sigue siendo grasa de la que debemos cuidarnos y de la que debemos aprender. Usar librerías con 11 líneas de código se convierte en una vaguería por no intentar cocinar nosotros. Por no cocinar nuestras propias soluciones, hemos puesto en peligro nuestro trabajo y la salud de nuestra aplicación. Tengamos cuidado.

3. Hacer ejercicio

Muchas veces, estos atracones de frameworks y librerías que nos damos, vienen provocados por no dedicar el tiempo necesario en ejercitarnos. La formación siempre es importante para cualquier persona y profesional y en nuestro trabajo, que sufre un cambio constante lo es más.

Sin embargo, hay que orientar bien esta formación. Estamos dedicando un número muy alto a aprender sobre estos frameworks y librerías (yo soy el primer entusiasta y muchas veces me tengo que parar los pies) y no dedicamos el tiempo necesario para aprender las bases, para aprender aquello que necesitamos.

Muchas veces acudimos a por librerías externas porque pensamos que es la solución más cómoda y la que mejor hecha va estar. Si nosotros tuviésemos unas bases sólidas sobre buenas prácticas, programación funcional y orientada a objetos, sobre programación pura, estructura de datos y de componentes, sobre ensambladores, sobre lenguajes de programación útiles, sobre testing, repositorios de código, creo firmemente que acudiríamos mucho menos a estas fuentes o seríamos mucho más selectos con la grasa que queríamos para nuestra aplicación

Conclusión

Cuidarnos con estos tres factores, o por lo menos pensarlos muy bien cuando estemos montando una aplicación, puede ayudarnos a que nuestro día a día sea mejor y nuestras aplicaciones sean más mantenibles. Creo que nuestros clientes y compañeros lo agradecerán 🙂

Nos leemos

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s