La mayoría de las horas gastadas en la profesión de programar se gastan en corregir errores. Todos los sistemas arrojarán errores, la única pregunta a resolver es: ¿dónde?, y ¿cuándo?. Una mala práctica, muy común para reparar los bugs que te reportan, es querer utilizar el debugger como recurso inicial. El debug debe ser tu última opción, no la primera. A continuación de explico por qué.
El debugging es improductivo.
No hay una actividad que demande más 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 tomará horas o días, corregir el error mucho menos. Has gastado más tiempo en preparar un sistema para reparar un error que comprobando el error mismo. ¿Y qué ocurre con todo este esfuerzo una vez reparado el sistema?, nada. Todo será 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 repita el bug.
La alta complejidad lo empeora todo.
Un debugging costoso no es la enfermedad, es más 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. Empezarán 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á.
Verificar 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. O sea, 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 estás ganando productividad.
El debug no debe ser profundo. Nunca permitas que los bugs vayan más 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, será 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 más rápido posible. No está de más 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 más que tienes a tu disposición para trabajar. Por sí misma no es mala, es el contexto donde la emplees 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 más debugging que utilices. Es necesario aplicar cambios en el equipo de trabajo. Existen métodos más eficientes y que reportan mejores resultados que el desarrollo orientado a debugging.
Autor imagen: heipei
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20
