El debugging debe ser el ultimo recurso del programador, no el primero.

La mayoría de las horas gastadas en la profesión de programar se gastan en corregir errores. Todos los sistemas arrojaran errores, la única  pregunta a resolver es: ¿donde? y ¿cuando?. Una mala practica, muy común  para reparar los bugs que te reportan, es querer utilizar el debugger como recurso inicial. El debug debe ser tu ultima opción, no la primera. A continuación de explico porque.

El debugging es improductivo.

No hay una actividad que demande mas tiempo, concentración  y reporte tan pocos beneficios como debuggear. En sistemas muy grandes, complejos o acoplados, la única manera a la que podrás acceder al estado erróneo es mediante el depurador. Todo esto es un ritual, desde configurar los entornos en tu equipo de desarrollo o los depuradores remotos. Buscar los insumos de entrada que suelen ser pasos en las interfaces de usuario. Hasta poner los breakpoints en los fuentes para ir delimitando el error. Esto te tomara horas o días, corregir el error mucho menos. Has gastado mas tiempo en preparar un sistema para reparar un error que corrigiendo el error mismo. ¿Y que ocurre con todo este esfuerzo una vez reparado el sistema?, nada. Todo sera echado a la basura, no hay garantías que la corrección persista. No hay documentación del conocimiento adquirido solo la esperanza de que no se vuelva a repetir el bug.

La alta complejidad lo empeora todo.

Un debugging costoso no es la enfermedad, es mas bien un síntoma. La verdadera enfermedad se llama alta complejidad, es un mal crónico que  afecta a las aplicaciones.  Sin un debido control todo sistema se volverá tan complejo que ni todo el equipo completo sabrá que hace el sistema. Empezaran a surgir lagunas mentales de conocimiento, por lo tanto la posibilidad de codificar fallos y entorpecer el soporte al sistema se ve incrementada. Es un mal silencioso, casi como un tumor maligno. El equipo de desarrollo no se dará cuenta hasta que sea demasiado tarde.

No basta con corregir el bug. Hay que garantizar que no se repetirá.

Corregir un bug en el sistema puede tener un coste alto. Y por esta razón debes de garantizar que no volverá a ocurrir. No, tu palabra no cuenta, ni cualquier argumento que des. Se requiere de evidencia física que lo garantice. Osea, estoy hablando de pruebas. Puedes incluir nuevos casos de prueba o codificar nuevas pruebas unitarias. Cualquier hora gastada en garantizar que no volverá a presentar un bug es una inversión que da intereses. Si desperdicias menos horas debuggeando el mismo error, entonces estas ganado productividad.

El debug no debe ser profundo. Nunca permitas que los bugs vayan mas abajo.

Todo estado erróneo en tu aplicación debe ser manejado en el contexto que ocurrió. Es preferible terminar la ejecución de un programa que permitir una ejecución lisiada. Cada nivel de profundidad que atraviese el error, sera un nivel que tendrás que recorrer a través del debugging. Debes de producir componentes con bajo acoplamiento y aislables que te permitan depurar tus objetos lo mas rápido posible. No esta de mas decir que los principios de SOLID son tu mejores amigos a la hora de reducir el tiempo que usaras el depurador.

Conclusiones.

Depurar es una herramienta mas que tienes a tu disposición para trabajar. Por si misma no es mala, es el contexto donde la uses lo que ocasiona improductividad. No es lo mismo depurar un nivel o dos de profundidad de componentes, que hacerlo con siete u ocho niveles. Si no puedes aislar tus componentes en tu sistema, existen problemas. Si requieres de muchas horas para poder reproducir un error, existen problemas. Los problemas no se van a ir por mas debugging que uses. Es necesario aplicar cambios en el equipo de trabajo. Existen métodos mas eficientes y que reportan mejores resultados que el desarrollo orientado a debugging.

Autor imagen:  heipei