¿Cuál es la ventaja de evitar el uso de un depurador?

Lo que parece ser adivinar desde el exterior a menudo resulta ser lo que yo llamo "depuración en tu mente". En cierto modo, esto es similar a la capacidad de los grandes maestros para jugar al ajedrez sin mirar un tablero de ajedrez.

Es por lejos la técnica de depuración más eficiente que conozco, porque no requiere ningún depurador. Su cerebro explora múltiples rutas de código al mismo tiempo, lo que le brinda un mejor giro que el que podría obtener con un depurador.

No estaba consciente de esta técnica antes de ingresar brevemente al mundo de programación competitiva , donde usar un depurador significaba perder preciosos segundos. Después de aproximadamente un año de competencia, comencé a usar esta técnica casi exclusivamente como mi primera línea de defensa, seguido del registro de depuración, con el uso de un depurador real en el tercer lugar distante. Un efecto secundario útil de esta práctica fue que comencé a agregar nuevos errores a un ritmo más lento, porque la "depuración en mi mente" no se detuvo cuando escribí un nuevo código.

Por supuesto, este método tiene sus limitaciones, debido principalmente a las limitaciones de la mente al visualizar múltiples rutas a través del código. Aprendí a respetar estas limitaciones de mi mente, recurriendo a un depurador para corregir errores en algoritmos más avanzados.

Cuanto más conozco un código base, menos necesito un depurador (pero aún así revisaría el error reportado, es una pista importante en cualquier razonamiento).

Es una buena herramienta para comprender un comportamiento dinámico de complejidad pequeña a mediana, pero a menudo descubro que me enfoca en los detalles en lugar de en la imagen general. Y después de un tiempo, ahí es donde están los problemas: en las interacciones de mayor alcance, cuyo comportamiento dinámico tiende a ser más fácil de entender con otras herramientas (registro de entradas y salidas en los límites de los módulos, por ejemplo).

Puede que no sean malos programadores, pero probablemente sean solucionadores de problemas terriblemente ineficientes.

Suelo seguir los consejos de Depuración: las 9 reglas indispensables para encontrar incluso los problemas de software y hardware más difíciles de encontrar (David Agans), y este cae directamente bajo la guía de "Deja de pensar y mira"

Cualquier trabajo requiere usar las herramientas adecuadas de la manera correcta. Si tiene un depurador, utilícelo para ver qué está sucediendo realmente. La mayoría de los errores son causados por suposiciones.

He trabajado con desarrolladores que se niegan a usar depuradores porque sabían mejor. La respuesta clásica que obtuve una vez fue "el accidente no fue causado por mí, pasé todo el día inspeccionando el código [donde se estaba estrellando] y no hay nada de malo". (¿Qué hay de ese valor nulo que se leyó en la base de datos?) El jefe pareció pensar que fue una gran respuesta, pero el cliente no lo hizo.

Me bajé de ese equipo tan rápido como pude. Su propósito era abombar el trabajo y convertir un simple problema de 10 minutos en un problema de todo el día.

Su mejor guía para la práctica de depuración es el libro de Steve McConnel Code Complete . El Capítulo 23 cubre la depuración en detalle, y destilaré algunos puntos de ella.

1. Comprender el problema es importante, y el uso del depurador no lo sustituye.
2. Adivinar es un mal enfoque para la depuración. Si sus colegas realmente están usando conjeturas, en lugar de pensar en el problema, entonces están haciendo un mal trabajo. Adivinar significa pegar declaraciones impresas al azar en el código y esperar encontrar algo útil.
3. Si sus colegas realmente no saben cómo usar un depurador (en lugar de elegir no usar uno), entonces sí, son incompetentes, al igual que alguien que no conoce la sintaxis del lenguaje que se supone que son. utilizando.

Difícil de decir. La depuración adivinando podría funcionar si ya tiene una idea acerca de cuál es el error (se pasó un valor incorrecto a una función de biblioteca, posiblemente un SQL no válido, etc.). Admito que lo hago a veces cuando el error parece pequeño o obvio, como "búfer de caracteres demasiado pequeño": el seguimiento de la pila me muestra la línea en la que falló y no necesito un depurador para resolver esa.

Hacer esto todo el tiempo puede ser contraproducente y si las primeras "suposiciones" fallan, adivinar es probablemente la estrategia incorrecta de resolución de problemas y se debe llamar a un depurador real. Normalmente, Digo que no hay nada de malo en usar el depurador.

Dicho esto, he trabajado con herramientas y entornos en los que era tan difícil que el depurador funcionara bien, o tan mínimo e inútil que, lamentablemente, a menudo el adivinar es un mejor enfoque. He trabajado con algunas herramientas propietarias que ni siquiera tenían los debuggers adecuados. Supongo que es posible que si una persona trabajara en tales entornos demasiado tiempo, eventualmente perdería su confianza en los depuradores y confiaría únicamente en el enfoque de la adivinación.

Me sorprende que la discusión sobre este tema no haya mencionado "pruebas de unidad".

Debido a que hago un desarrollo guiado por pruebas, no paso mucho tiempo en el depurador. Hace 10 años, solía pasar diligentemente a través del depurador:

1. Después de escribir un fragmento de código para asegurarse de que funcionó y
2. Cuando recibí un informe de error para intentar diagnosticar el problema

Lo que he encontrado después de 10 años de desarrollo basado en pruebas es que soy mucho más productivo como programador si:

1. Escribo pruebas unitarias antes Escribo el código para asegurarme de que lo escribí correctamente
2. Escribo pruebas unitarias inmediatamente después de recibir un informe de error para intentar duplicar y profundizar en el problema.

Permitir que la computadora ejecute el código y valide el resultado es miles de veces más rápido de lo que puedo pensar o paso a través del código para validar mentalmente los resultados, y no comete errores.

Todavía tengo que pasar por el depurador de vez en cuando, y sigo involucrado en analizar mentalmente el código ... pero solo en raras ocasiones, y sobre todo para código muy delicado.

Personalmente, trato de minimizar el uso de un depurador mediante:

• utilizando comprobadores estáticos y opciones de compilación similares que sugieren posibles fuentes de errores simplemente analizando el código
• escribiendo código con la menor cantidad de efectos secundarios posibles, en el estilo más funcional posible, eliminando el estado mutable cuando sea posible
• escribiendo pruebas unitarias con la granularidad razonable mínima
• no tragar excepciones

Por supuesto, todos cometen errores, por lo que incluso al componer programas de esta manera, si una prueba falla, uso el depurador para inspeccionar el valor de una expresión intermedia. Pero al adherirse a los principios anteriores, el defecto es más fácil de localizar y la depuración no significa un proceso doloroso e indeterminista.

Utilice el depurador siempre que sea posible. El depurador simplemente solucionará el problema (oh, mira, no verificamos este valor), o proporcionamos una gran cantidad de contexto que es útil al analizar el código relevante (wow, la pila está totalmente desordenada, voy a ya que es un problema de desbordamiento de búfer).

La depuración es una herramienta muy útil para inspeccionar el estado de los objetos y las variables en su código en tiempo de ejecución.

Como se mencionó anteriormente en las respuestas anteriores, la depuración es extremadamente útil, pero hay algunos casos en los que es limitado.

En mi experiencia, el uso del depurador es muy útil porque ayuda a revelar suposiciones falsas que estaba haciendo sobre el estado de mi código. Algunas personas no son tan astutas a la hora de leer el código para encontrar un error, por lo que la depuración puede ayudar a revelar suposiciones falsas que usted u otro desarrollador hicieron sobre el estado del código.

Tal vez espere que un parámetro nunca sea nulo cuando se pasa a un método, por lo que nunca verifica ese caso y continúa con el método como si ese parámetro nunca fuera nulo. La realidad es que el parámetro hará terminará siendo nulo en algún punto, incluso si establece como condición previa al método que el parámetro nunca debe ser nulo. Siempre sucederá.

A diferencia de la utilidad de los depuradores en los ejemplos mencionados anteriormente, me resulta difícil y un poco inútil usarlos cuando se trata de subprocesos múltiples (es decir, concurrencia, procesamiento asíncrono). Puede ayudar, pero es fácil perder su orientación en la niebla de múltiples subprocesos cuando los puntos de interrupción del depurador están siendo alcanzados en un hilo en el punto A y en un hilo completamente separado en el punto B. El desarrollador se ve obligado a empujar el nuevo punto de interrupción " proceso de pensamiento "en la parte superior de la" pila "de su cerebro y orientarse a sí mismo al código en el punto del nuevo punto de interrupción. Después de que la relevancia del punto de interrupción B disminuye, el desarrollador vuelve al primer punto de interrupción y tiene que recordar lo que buscaba antes del desencadenante del punto de interrupción B. Sé que esto puede ser una explicación confusa, pero mi punto en este párrafo es que la depuración donde se usa la concurrencia puede ser muy AGREGABLE (Trastorno de déficit de atención), por lo que puede ser más difícil seguir siendo productivo en su patrón de pensamiento de depuración.

También la imprevisibilidad del código concurrente puede distraer aún más al desarrollador en la depuración del código concurrente.

En conclusión, en mi sincera opinión:

• Depuración cuando se usa la concurrencia = mayor tendencia a perder el enfoque del "patrón de pensamiento de depuración"

y

• en cualquier otro momento = aumento de la productividad de depuración b / c, su atención no se ve interrumpida por puntos de interrupción inesperados (inesperados debido a las condiciones de la carrera).

Creo que están siendo un poco demasiado hardcore. Personalmente, cuando me encuentro con un error, vuelvo a verificar el código, trato de rastrearlo mentalmente desde la lógica del programa, porque a veces eso me ayuda a descubrir otros problemas o efectos secundarios más fácilmente que simplemente usar el debbuger y corregir el error donde se manifiesta. .

Incluso cuando creo que lo he clavado, generalmente lo depuro para asegurarme de que estoy en lo cierto. Cuando el problema es un poco más complejo, creo que la depuración es absolutamente esencial.

También ... solo mi opinión, pero no hay excusa para no tomar una ventaja decente de las herramientas que un IDE moderno puede traer a la mesa. Si le ayuda a completar su trabajo más rápido y de manera más confiable, debe usarlo.

Odio generalizar, pero muchos programadores que he conocido piensan que solo hay una manera de resolver un problema (su forma). Es fácil suponer que se han pensado todas las pruebas posibles. Una perspectiva diferente puede ser muy valiosa.

La programación por prueba y error puede dar lugar a nuevos y excelentes enfoques y detectar cosas que otros no han podido ver.

La desventaja, generalmente toma mucho más tiempo.

Erm, depende de la persona. Personalmente, yo no uso mucho a los depuradores. Cuando programo microcontroladores, básicamente uso LED o escribo datos en EEPROM para "depurar" el código en él. No uso JTAG.

Cuando programo software para PC o servidores, tiendo a usar el registro y una gran cantidad de resultados de consola. Para los lenguajes de estilo C, uso directivas de preprocesador y en Java usé niveles de registro.

Ya que no uso los depuradores, ¿diría que estoy haciendo algo mal? Son los trabajos de los editores, para mostrarme dónde tengo errores sintácticos, y cuando hay un error lógico, solo tengo que realizar pruebas.

Hay una diferencia entre no necesitar usar un depurador y no saber cómo (o rehusarse) usar un depurador. El depurador es solo una de las muchas herramientas para usar en el seguimiento y solución de errores. He trabajado con desarrolladores que pueden descifrarlo en su cabeza y otros que piensan que pueden hacerlo.

La mejor combinación es escribir su código para que sea fácil de probar mediante pruebas unitarias y registre los errores. Entonces espera no tener que mirar los registros o usar el depurador. Es como comprar un seguro. Es de esperar que nunca necesite usarlo, pero una vez que se encuentra con un error que no puede resolverse volviendo a verificar el código, es demasiado tarde para agregar el manejo / registro de errores adecuado, las pruebas unitarias o aprender a usar un depurador.

Diferentes herramientas / plataformas favorecen diferentes técnicas de depuración (depurador, registro, pruebas unitarias, etc.) Siempre que un desarrollador esté familiarizado con algunas de las técnicas para su plataforma / herramienta, además de solo volver a verificar el código, entonces pueden ser un desarrollador experto, pero si solo tienen un truco cuando se trata de depurar, eventualmente se encontrarán con un error que no podrán encontrar o solucionar.

Muchas respuestas, pero no una mención sobre Heisenbug ?!?!

  

Los Heisenbugs ocurren porque los intentos comunes de depurar un programa, como   insertando sentencias de salida o ejecutándolas en un depurador, generalmente   modificar el código, cambiar las direcciones de memoria de las variables y   momento de su ejecución.

Utilizo el depurador, solo en el peor de los casos (para errores difíciles de encontrar). Además, según las mejores prácticas de las que han estado hablando muchos desarrolladores / probadores aclamados, es bueno probar el código a fondo. De esa manera, puede cubrir la mayoría de los problemas y, por lo tanto, no habría necesidad de utilizar el depurador.

Leí un argumento en contra de la depuración del depurador aquí recientemente (¿o fue StackOverflow?). Debe tener casos de prueba en contra de su código. Si sus pruebas pasan, su depuración probablemente no va a ejercer el error (suposición: se depurará con datos similares a los de su prueba).

Por otro lado, el registro es obligatorio. Si pasa sus pruebas y las implementa en producción, es posible que tenga un error. La evidencia del error es de algo que sucedió en el pasado. es decir, alguien dice: "¿Cómo llegó eso allí?" Si no tiene buenos registros, nunca encontrará la causa. Incluso un depurador puede ser inútil en ese momento porque no sabes cómo se ve la información que realmente ejerció el error. Debe poder depurar la aplicación de los registros.

Desafortunadamente, estoy parafraseando un poco, y es posible que esté haciendo un daño al argumento original. En particular, la posición de "Hay importantes asistentes de depuración para dedicar tiempo de desarrollo al apoyo" podría ser ortogonal a la importancia de los depuradores. Pero la parte sobre la dificultad de establecer el estado del sistema en una configuración que hace que la depuración sea útil para encontrar errores me pareció algo en lo que pensar.

Con buenas pruebas de unidad y las excepciones que le proporcionan el seguimiento, rara vez tiene que usar un depurador.

La última vez que utilicé una depuración fue cuando obtuve un archivo central en alguna aplicación heredada.

  

¿Estoy siendo un "secuaz de debbuger" o estos chicos son "demasiado duros"?

Ninguno. Solo son gente que le gusta hacer la vida más difícil de lo que debería ser.

La depuración es solo una herramienta que un buen desarrollador debe usar con habilidad.

Ciertamente, a veces puedes saber de memoria dónde puede estar el error si conoces el código base. Pero también puedes perder un día entero o una semana para encontrar un bicho molesto solo con mirar el código.

En idiomas tipificados dinámicamente sin algún tipo de depuración (incluso si solo se están descargando valores a la consola) a veces resulta imposible adivinar.

Entonces, para responder a tu pregunta, tal vez sean programadores brillantes, pero sus habilidades de solución de problemas y su habilidad para detectar errores son malas.

Depende del alcance de un problema. Si el programa es pequeño y las cosas están bien divididas, probablemente pueda averiguarlo mirando. Si el programa es de 4.5 millones de líneas de código desarrollado por un equipo de más de 100 personas a lo largo de varios años, será imposible detectar ciertos errores.

El que está en cuestión en dicho programa (en C) fue una sobrescritura de memoria. El depurador con un punto de interrupción de memoria identificó la línea de código ofensiva tan pronto como apareció el error. Pero en este caso, no hay forma de que alguien haya leído y retenido los 4.5 millones de líneas de código para identificar el lugar donde alguien escribió más allá de su matriz (además, tendrían que haber conocido el diseño de tiempo de ejecución de la memoria para el estado del programa gigantesco) aproximadamente 10 minutos en una larga serie de entradas para llegar a ese punto).

siendo el punto: en programas pequeños o cosas que están altamente modularizadas, puede alejarse sin un depurador. Si el programa es realmente grande y complejo, el depurador puede ahorrarle mucho tiempo. Como han dicho otros, es una herramienta y tiene situaciones en las que sobresale por encima de cualquier otro método, y otras donde no es la mejor opción.

Si el error se produce en la computadora de un cliente, o en una computadora que su entorno es muy diferente al suyo, entonces configurar un depurador / depurador remoto es engorroso. Entonces, para el día frío en el que recibes un error del campo, la respuesta de 'pero ... no tengo un depurador' no ayuda. Por lo tanto, debe desarrollar un conjunto de habilidades para solucionar problemas y encontrar el error solo mediante la comprensión del código y los archivos de registro.

Qué tontería: "Los programadores reales no necesitan depuradores". También puedo decir que un programador de verdad no necesita ningún IDE, solo dame un cuaderno de notas y un lápiz sin brillo. El depurador es una herramienta como cualquier otra que ayuda a la productividad.

Además, tenga en cuenta que no todas las personas encargadas del código de depuración están familiarizadas con ese código en cuestión. Muchos contratistas de tiempo entran en un entorno donde solo tienen un ideal general de lo que está sucediendo. Incluso se les puede dar una descripción detallada de un entorno, o un mapa de esquema de 20 años y una guía de convenciones de nombres arcanos (intente comprender la diferencia entre la tabla X1234 y la tabla X4312 con los campos F1, F2 y F3 [sí, basura como esta existe] cuando eres nuevo), pero muchas veces esa descripción es incorrecta; de lo contrario, ¿por qué hay un error de "misterio"?

Como alguien nuevo en un entorno, puede pasar horas o días mapeando y "conociendo" una gran base de datos para un área problemática que puede solucionar y que nunca más tendrá que volver a consultar. Esto es una enorme pérdida de tiempo y dinero. Si tiene acceso al depurador, puede ver lo que está sucediendo, corregirlo y desaparecer en cuestión de minutos. Todo este "no necesitas depuradores", es simplemente un puffery elitista.