Depurar el código tal vez no sea la respuesta indicada si es que se necesita entender el proceso de un negocio en particular.
Menos aun si es que si quiere identificar de buenas a primeras un problema.
Menos aun si es que estamos hablando de la depuración línea por línea.
No estoy en contra de la depuración, no he dicho eso.
Con lo que no estoy de acuerdo es con el uso incorrecto que se le dá, a veces pienso que el termino apropiado es «abusar» de tal funcionalidad.
Considero que si tenemos que depurar una aplicación es debido a un funcionamiento no esperado de la misma, algo que el código no tenia contemplado, si… una excepción a la regla.
Correcto, una parte de la depuración debe ser cubierta por el manejador de excepciones,
Pues claro, dado a que, si sucede un problema en el código, uno no debería preguntarse dónde comenzar, menos aun basarse en corazonadas del tipo «a ver, en que ventana se cae?«. (A menos claro, que uno termina cayendo por las corazonadas, observaciones y/o experiencias)
Si es que estamos en una construcción debemos tener en cuenta que el mensaje de error nos tiene que entregar información suficiente que sirva como base para identificar el problema.
En este caso la corazonada se convierte en pregunta del tipo «veamos el mensaje de error»
Es muy cierto que con el tiempo una persona termina preguntando «qué dice el mensaje de error?» (incluso por teléfono), pero la idea es que la descripción entregada por la misma sea comprensible por personas de menor experiencia.
Cómo se logra esto? si estamos en etapa de construcción, el detalle debe ser explícito, incluyendo información del stack (okey, creo que fui demasiado técnico), es decir hay maneras de obtener incluso la línea de código que presenta el problema.
Con esto ya sabriamos donde comenzar y el espectro de revisión será cada vez menor.
Y eso que no estamos mencionando aspectos muy importantes como lo son, las pruebas unitarias.
Cuando el rango de revisión es cada vez mas pequeño, estamos obligados de manera inconsciente, a reemplazar la depuracion línea por línea por una revisión del código manteniento un correcto uso de los puntos de interrupción (es decir, por ejemplo, antes y despues de la llamada a una función).
Claro, que esto puede lograrse mientras mas información del error se tenga. Y si estamos hablando de construcciones propias, pues podemos controlarlo, o no?
Ahora, si estamos hablando de algun legado que tenemos que terminar de construir o agregar funcionalidad y este sistema no cuenta con un manejador de excepciones o tiene mensajes no apropiados al ojo humano (es decir, error general, por favor, arreglame), pues preparense, que necesitan paciencia.
Saludos[at]Trabajo
Cross from here