Warning: Declaration of TCB_Menu_Walker::walk($elements, $max_depth) should be compatible with Walker::walk($elements, $max_depth, ...$args) in /home/wuaup172/public_html/wp-content/plugins/thrive-leads/tcb/inc/classes/class-tcb-menu-walker.php on line 0
No soy capaz de arreglar el maldito bug!
"El lado humano del software"

No soy capaz de arreglar el maldito bug!

Soluciones a un error imposible. Por más herramientas de depuración de última tecnología, siempre va a existir algún bug que nos va a dar guerra. Lo primero que solemos hacer es estudiar un poco el tema y realizar el clásico ensayo de prueba/error usando la traza, puntos de depuración, o utilidades. Si el error se resiste solemos ir a “San Google” y ¿si no encontramos nada útil? En ese momento empieza el agobio… ¿qué hacer?

Es típico en los siguientes escenarios:

  • Cuando depuramos código de algún programa complejo del que no tenemos ni idea, porque su creador original fue despedido.
  • Al manejar alguna librería cerrada (compilada) que recibe un formato de datos y realiza alguna transformación.
  • En sistemas complejos que incluyen muchas cosas y fallen en algún punto.

 

¡No hay un mejor sitio para encontrar un bug que la ducha!

Pensar soluciones fuera del contexto de trabajo puede funcionar.

Ahora bien, con independencia de los trucos creativos, necesitamos de un método.

La fuerza bruta no sirve, podríamos probar miles de configuraciones y el error seguiría reproduciéndose.

 

 

Quedan dos alternativas:

  • Pensar que es posible que el error inexpugnable no se deba a un sólo error, sino por la conjunción de dos o más errores, que al sumarse producen resultados extraños.
  • Una vez descartado que no tenemos errores cruzados procederemos a la búsqueda binaria de la solución.

La búsqueda binaria de prueba y error lleva siempre hacia el éxito, aunque no tengamos ni idea.

El truco consiste en dividir el proceso en dos partes muy grandes, no ejecutando u omitiendo los datos de una mitad en el caso de que sea un proceso de transformación, y probar. Generalmente, obtendremos el error en un 50% y en el otro un funcionamiento correcto.

En la búsqueda binaria de errores nuestro tiempo debe centrarse en pensar cómo hacer para subdividir el proceso.

En el 50% que ha fallado volveremos a realizar la misma técnica, subdividir nuevamente el proceso a otro 50%. Es binario puro, si tenemos mala suerte puede ser que tengamos que realizar muchas pruebas, llegando a ser lento si cada prueba requiere de tiempo de procesado y de pasos manuales, pero siempre lleva al éxito.

Teniendo en cuenta que no encontrábamos la solución, puede ser una alternativa válida.

Si recordamos el mundo binario, vemos que cada intento divide entre dos el tamaño de cada segmento hasta localizar el maldito bug, es decir, con 1 prueba solo distinguimos entre dos bloques, con 2 pruebas 4… con 8 pruebas 256 bloques, con 16 pruebas 65536 bloques y con 32 pruebas miles de millones de bloques, con lo cual, al ser cada vez más pequeños no hay elementos complejos que se resistan, llegaremos al punto del fallo sí o sí.

Al final siempre aparece la aguja escondida

Sólo una cosa más, mejor pensar en el error como un reto mental, un juego y dejar las frustraciones en el cajón.

¡Feliz trabajo y feliz codificación! 😊

P.D. Por cierto, quizás sobre decir esto, pues es más viejo que el dinero, pero reiniciar el equipo a veces funciona. Si, lo digo a los informáticos. Por más que se sepa es bueno recordarlo… yo mismo he llegado a ser tan patético que sumergido en las complejidades de mi super código de programación he olvidado este principio elemental y me he comido estúpidamente horas de trabajo…

 

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.