Un bug es un error en la programación. Un comportamiento imprevisto e indeseado de un programa.
En general se da para una situación que no provimos al programar, o para casos que no consideramos o para una instrucción que usamos mal.
Si alguien pregunta que es un bug…es porque no sabe programar.
¿Cómo lo encuentras?
Lo encuentras cuando ejecutando un programa se da la situacion inesperada. Ejemplo: Estoy agregando un voto positivo a un comment, y noto que por cada voto positivo, en vez de sumarse uno, se suman 2.
Pero la pregunta es
¿Cómo lo encuentras en el código?
Hay que buscar la instrucción que suma los votos y pensar todas las formas en que el programa puede llegar a él.
En general lo ideal sería hacer un análisi del programa y por ese análisis pensar qué instrucción está generando ese mal comportamiento. Tal vez notemos que el «votar positivo» llama 2 veces al «sumar votos» en vez de una vez.
Otra forma es usar un debugger. El debugger es una herramienta que te permite ejecutar un programa paso a paso.. Los programas en general van ejecutando instrucciones que cambian los valores de variables, haciendo que cada instrucción cambie algo del entorno.
Entonces podemos pensar un programa como un conjunto de eventos que causan cambios en un universo. Con el debugger podemos parar el universo luego de cada evento, y mirar el estado de ese universo en ese instante. Eso nos permite hacer un analisis más controlado de lo que sucede.
Hay entornos donde esto es mas dificil porque no se ejecuta una instruccioon a la vez sino que muchas cosas concurrentes suceden. Entonces hay errores que es mucho más dificil descubrir porque se dan esporadicamente frente a muchas condicioens.
Una herramienta que tenemos para encontrar este tipo de errores son los «logs» . Loggear significa dejar rastro de cada cosa que va pasando (adicional a lo que el sistema tiene que hacer)
Entonces podemos ejecutar un programa y luego leer los logs y tratar de entender lo que realmente sucedio. Eso nos da la posibilidad de rastrear un error en un entorno real donde no podemos replicar el ejemplo En general se guardan logs en los sistemas empresariales, por lo que es importante cuando se reporta un error decir a qué hora sucedió, para que los programadores puedan rastrear los logs cercanos a ese momento.
Hay errores que son dificiles de rastrear porque cada cambio , cambia el contexto. Y ciertos errores se dan solo cuando el contexto anterior fue cambiado. Entonces el error no esta en la instruccion que lo hace saltar sino que ocurrio mucho tiempo despues.
Ejemplo en el sistema de votos. Supongamos que cuando aplicas el voto suma 1 a la suma de votos anteriores.
Ejemplo : sumaVotos = sumaVotos +1
Pero en alguna instruccion anterior alguien ya ejecuto
sumaVotos = «Hola»
Si el lenguaje no controla tipos eso no seria un error
Cuando votas y llama a sumaVotos = sumaVotos +1
Se genera el error porque no puede sumar letras y numeros. Pero el verdadero error ocurrio antes. En estos casos particulares tambien son de mucha ayuda los logs dejando el rastro del valor que va tomando cada variable.
Los debuggers tambien tienen herramientas para suspender el programa (para controlarlo) cuando el valor de una variable cambia. Entonces no hay que recorrerse paso a paso todo el programa.
Busqueda Binaria
Y menciono una alternativa mas cuando ya estamos perdidos y plenamente derrotados y ya no se nos ocurre por donde esta el problema.
Y es la busqueda binaria.
Es tratar de dividir el programa en 2… y ver si podemos tener una parte que seguro anda bien y otra en la que falla.
Entonces tenemos que aislar lo que anda bien (como un ancla que tenemos «segura»)
Y una vez que tenemos esas dos partes, en la parte errónea aplicar la misma técnica y dividirla en 2, y asi sucesivamente hasta encontrar el problema.
Esto puede implicar … no solo «ejecutar» la parte erronea, sino construir un nuevo proyecto que tenga solo lo que falla.
O construir un proyecto que funcione lo que en el otro falla.
Ejemplo: Nos tiene que pintar de rojo una palabra y aparece verde. Bueno… armar un proyecto que no tenga nada que ver que lo pinte de rojo… e ir «mergeando» uno en el otro… combinandolo hasta que el malo ande bien o que el bueno fallle y entender la condicion de error.
No ponerse nervioso ni enojarse
No ponerse nervioso frente a los bugs. Es parte del trabajo. Si no hubiese bugs o unexpected conditions, sería un trabajo administrativo. Y al elegir desarrollar software elegimos un trabajo que no es repetitivo o administrativo. Es obvio que van a surgir condiciones inesperadas o no triviales que no se comporten como habiamos pensado.
La otra parte del trabajo es poner buenos nombres, nombres que sean significativos y tengan que ver con el negocio para que todos , inclusive las siguiente generaciones que vean el programa entienda cual fue la intencion de cada parte
Y otra cuestión es saber que HAGAMOS LO QUE HAGAMOS … en el futuro NOS VAMOS A OLVIDAR. Entonces aún para nosotros dejar rastro de lo que hacemos con comments y con logs. A veces en una pasada o un intento el bug no se encuentra… pero lo que podemos hacer es agregar logs que sean mas significativos para que la próxima vez que ocurra tengamos más elementos para rastrearlo.