Las 10 peores pesadillas de un programador web - Parte 1

Con motivo de Halloween publicamos las 10 pesadillas más comunes de los desarrolladores web. Pido disculpas de antemano por estos artículos tan terroríficos, pero de verdad, nos veíamos en la situación de publicarlos. Serán una serie de dos artículos y en ellos os revelaremos aquello que da más miedo a los desarrolladores web. Comenzamos con las pesadillas...

1. Solucionar códigos de otros desarrolladores

Si te acabas de incorporar a nueva empresa, lo más probable es que comiences haciendo limpieza de un proyecto que dejó el desarrollador al que acabas de reemplazar. De seguro que se trata de un código largo, realmente complejo, ilegible, y lleno de bugs... Por supuesto, podrías ser el 5% afortunado que no tiene dedicarse a estas tareas nada más debutar en su nuevo oficio, pero debo decirte que el picar código de otros desarrolladores está siempre a la orden del día en el mundo de la programación.

El problema surge porque los desarrolladores, como escritores, tienen su propio estilo de codificación. Aquí es donde la documentación se convierte en un regalo del cielo. Si tú siempre has renegado de documenar tu código, te lo pensarás dos veces cuando te toque leer y leer líneas de código ajeno el cual tendrás que descifrar para qué funciona cada cosa. Creeme si te digo que incluso puede peligrar tu salud mental.

2. Errores que aparecen en el peor momento posible

Después de meses de duro trabajo y toneladas de cafeína, finalmente has lanzado tu aplicación al mundo o la has presentado al cliente. Estás muy emocionado porque por fin puedes ver la luz al final del túnel, después de meses de duro trabajo echando horas como un animal. Pero de repente un error crítico ocurre durante la demostración, o provoca quejas de cientos de nuevos usuarios. El sueño de tu proyecto perfecto se viene abajo...

En primer lugar, sabemos que esto le puede suceder a cualquier persona - incluso a los desarrolladores de plataformas grandes como Facebook y Twitter. Para los que han pasado por esto, sabéis lo frustrante que puede ser esta situación; llegan las malas críticas y los clientes te miran como si hubieras cometido el crimen más sucio del mundo.

Ante esto mantén la calma. Corrige los errores lo antes posible y simplemente no dejes que esto te arrastre hacia una espiral sin fondo... Verás que, cuando vuelvas a levantar cabeza, la tormenta ya habrá pasado...

3. Corriges un error y aparecen otros nuevos

La corrección de errores es un mal necesario. Una actividad tortuosa, improductiva y no apta para cardíacos, que te hace cuestionar por qué has querido dedicarte a esto del desarrollado. Todos hemos pasado por esto. Después de horas de teclear y teclear código, por fin has podido solucionar el error original. Todo es alegría, hasta que vuelves a ejecutar la página y... ¡OH DIOS MIO! ¡HAY 20 MÁS!

Deja de tirarte de los pelos y procura que esto no ocurra más. Para evitar que una situación similar ocurra con tus futuros proyectos, utiliza Git para administrar tus revisiones de código, ya que te permite revertir a versiones anteriores si la nueva no funciona correctamente. Además, recuerde documentar cada revisión con cuidado. Puede parecer una tarea super aburrida pero a la hora de la verdad, ten por seguro que lo agradecerás.

4. El bug reside en la librería en la que confías

¿Sabes lo que es una pesadilla aún peor? Cuando el error que has encontrado en el código no existe realmente en tu código, sino en una de las librerías que has utilizado. A menudo nos apoyamos en varias librerías para construir sitios web y los desarrolladores solemos utilizar las mismas para múltiples proyectos, sin que haya problema alguno. En este particular escenario, en el que compruebas que el origen del error es de una librería en la cual confías, ¿qué haces? Es un dilema, ¿no es así? Vamos a considerar las opciones.

  • Solucionar el error de la librería por tu cuenta. Es un trabajo arriesgado porque tendremos que volver a la pesadilla número uno, además de adentrarnos en tecnologías seguramente que desconozcamos y de las cuales tendremos que ponernos las pilas. Ponte la bandana de Rambo y a por ello.
  • Puedes contactar con el desarrollador que implementó la librería para comunicarle que está provocando un bug en tu proyecto. Suerte con ello, porque no te auguro una respuesta rápida y menos si nos has pagado nada por la librería.
  • Sustituir la librería por otra que tenga la misma funcionalidad. Es una buena opción, solo que tendrás que volver a reescribir los trozos de tu código que interactúen con la vieja librería... Eso ya depende de ti y de lo compleja que haya sido la implementación.

Ninguna de ellas es fácil. Sólo te queda rezar a los dioses de la programación para que nunca te ocurra esta situación. Aunque si eres programador, tarde o temprano, te toparás con ello.

5. La causa del bug es "desconocida"

No, esto no puede ser! Has estado buscando durante días ese bug, pero sigue siendo esquivo. Vas a StackOverflow a consultar al oráculo, pero solo encuentras una pregunta similar a la tuya que tiene cero respuestas. Tu cabeza comienza a girar, sigues diciendote a ti mismo que si gastas más horas en buscarlo, terminarás loco.

Detente. La solución a este problema es en realidad hacer lo contrario. Debes permanecer lejos del ordenador por medio día o más. Estás sufriendo de fatiga mental que te impide "ver" o "encontrar" el problema real. Tomate un descanso  y te ayudará a encontrarlo al 100%.

COMPARTE ESTE ARTÍCULO

COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN LINKEDIN
COMPARTIR EN WHATSAPP