Los programadores reales usan depuradores? [cerrado]

Si los programadores experimentados alguna vez usan depuradores, y si es así bajo qué circunstancias. Aunque en la respuesta a esa pregunta dije hace "meses", probablemente quise decir "años", realmente no uso un depurador. Entonces, mi pregunta específica de respuesta es, ¿bajo qué circunstancias usaría usted, como programador experimentado, un depurador?

Yo diría que no usar un depurador es un signo de inexperiencia. Recorrer el código línea por línea es la mejor manera de rastrear el flujo de ejecución.

Uso el depurador a menudo, porque trabajo en un sistema grande y, por lo tanto, apesta. http://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html

No importa cuán corto y con frecuencia se lea su código, siempre habrá la posibilidad de que tenga errores. http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

Errar es humano y uno nunca puede probar que un programa es correcto, entonces, ¿por qué no usar herramientas como depurador / pruebas automatizadas para ayudarnos en este difícil negocio?

Si el código es lo suficientemente corto, entonces se realizarán pruebas simples. Además, si es breve y conoce la naturaleza del error, la lectura del código puede ser suficiente. Sin embargo, una vez que la base del código es grande, involucra varios idiomas mezclados, más 3 niveles, entonces simplemente debe tener una buena cobertura de prueba en muchos niveles más un muy buen depurador; de lo contrario, perderá mucho tiempo.

Entonces, ¿cuándo no necesito un depurador?

No soy el programador más inteligente ni el más experimentado, pero aun así, a veces no necesito usar el depurador. Eso es cuando:

• El código es mío o bien escrito Y
• Está escrito en un lenguaje legible Y
• El proyecto general es pequeño.

¿Cuándo confío mucho en un depurador?

• Respuesta corta: a menudo .
• Cuando una aplicación falla. Particularmente cuando se implementa. Tener VS2010 instalado en esa computadora puede marcar la diferencia entre "Error desconocido" y FileNotFoundException.
• Cuando una biblioteca de terceros se bloquea o se porta mal.
• Cuando el código está mal escrito. Particularmente si el mismo archivo fue tocado por 10 personas diferentes en los últimos 10 años, 7 de los cuales ya no están en la compañía.
• Cuando el proyecto es grande
• Cuando el código es bastante monolítico.
• Cuando hay varios niveles (GUI, SQL, BL) involucrados.

Tenga en cuenta que "depurador" puede referirse a más de una herramienta. Utilizo el depurador de Visual Studio, el depurador de SQL (principalmente para los procesos almacenados) y el perfilador de SQL también (para averiguar qué SP se están llamando). ¿Necesitaría herramientas de este calibre si estuviera escribiendo un script Python sysadmin-ish rápido? No. ¿Si hice mi propia pequeña herramienta basada en GUI? Depende Si es .Net WinForms, probablemente no. Si es WPF, sí.

¿Qué define a un programador "real" de todos modos? ¿Uno que sea rápido? ¿experto? ¿Es bueno en algoritmos? Escribe buena documentación? ¿Cuándo se gradúa exactamente este nuevo título? ¿Cuándo se cruza la línea mágica?

Diría que un programador que no se ha ensuciado las manos en un esfuerzo existente de más de 100 años no ha tenido la oportunidad de sentirse humillado por la complejidad y las limitaciones propias (así como por la calidad del código).

Personalmente trato de usar el mejor depurador disponible para mí, y tiendo a usarlo con frecuencia. Si una tarea es lo suficientemente simple y no requiere un depurador, entonces no la uso. No toma mucho tiempo determinar si necesito uno o no.

...

Ahora, en teoría, podría leer la base del código durante tanto tiempo, que simplemente lo obtendría. Sin embargo, el enfoque práctico funciona mejor, además, a menudo quiero volver a escribir ese código estúpido que estoy viendo. Desafortunadamente, me llevaría más de 10 años limpiar la base de código en la que estoy. Por lo tanto, usar el depurador es un primer paso obvio. Solo cuando descubro cuál de las 5 millones de líneas de código está actuando, escanearé el archivo hacia arriba y hacia abajo para tratar de averiguar qué está haciendo esa clase.

"No me gustan los depuradores. Nunca lo he hecho, probablemente nunca lo haré". - Linus Torvalds

Por otro lado, él no tiene una cuenta de Stack Overflow, por lo que no estoy seguro de si le interesa su opinión :)

Entonces, mi pregunta específica de respuesta es, ¿ bajo qué circunstancias usaría usted, como programador experimentado, un depurador?

• Cuando no pueda "depurar" leyendo su código.
• Cuando no puede predecir qué valores tienen ciertas variables en un momento determinado.
• Cuando su modelo mental de su código no se ajusta a la salida dada por su código

Editar:

Tuve la fortuna / la desgracia de no saber cómo usar un depurador en mi viaje de programación. Por lo tanto, en el pasado me vi obligado a depurar sin un depurador. Sin embargo, después de aprender a usar un depurador -> me he vuelto 100 veces más productivo en la búsqueda de errores.

Para dar una perspectiva ligeramente diferente de las respuestas actuales; Como ingeniero de software integrado que trabaja en sistemas que a menudo tienen un componente en tiempo real, rara vez uso un depurador.

En ocasiones, un depurador puede ser una herramienta increíble y siempre que pueda construir y ejecutar código en un escritorio, siempre usaría un depurador.

En el chip, con restricciones en tiempo real, existe una gran carga asociada con el intento de usar un depurador. Tan pronto como detenga la ejecución, es probable que altere, posiblemente fatalmente, el tiempo del resto del sistema. Generalmente en chip, printf en código no crítico y IO wagging en código de tiempo crítico es la mejor y más simple herramienta. No es tan bueno como un depurador, pero es mucho más barato trabajar con un sistema real.

Creo que los programadores experimentados usan depuradores casi exclusivamente, cuando son necesarios. Qué mejor manera de localizar un error que seguir la ejecución del código ...

¿Asumes que los Skeets del mundo no cometen errores o simplemente lo saben todo? Todos, excepto los programas más triviales, se comportan de manera inesperada en algunas circunstancias. Es un hecho que los problemas tendrán que ser investigados. Entonces, las opciones son usar declaraciones de impresión, en un extremo del espectro, o examinar examinar lo que sucedió, post mortem, en el otro, o mirar justo en el medio a medida que se ejecuta el código y descubrir qué está sucediendo.

Quizás una mejor forma de pensar es que los programadores experimentados saben cuándo usar un depurador. En un código con pocas dependencias, mirar un seguimiento de la pila es probablemente suficiente para descubrir qué está mal. Pero hay escenarios complicados en los que su código funciona con otro código, y necesita un depurador para ver las cosas que no escribió.

No, y llevo programando más de 10 años. Solía ​​hacerlo, cuando programaba en c / c ++. Ahora programo en java. La verdad es que si está registrando correctamente, terminará con un seguimiento de la pila que es suficiente para la mayoría de los desarrolladores expertos. Además, si está escribiendo (buenas) pruebas unitarias y pruebas funcionales, eso elimina toda una clase de errores.

¿A quien le importa? Lo que quiero saber es si el uso de un depurador me impedirá ser un mejor programador a largo plazo. Tal vez los depuradores eran de menor calidad cuando muchos desarrolladores experimentados comenzaron, por lo que fueron un obstáculo. ¿Es una muleta que impide una comprensión más profunda?

Algún programador, probablemente mejor que el resto de nosotros, encontró la necesidad de un depurador y creó uno (no tengo idea de quién creó el primero). Estoy seguro de que fueron más productivos como resultado de ello. Dudo que la motivación fuera permitir a los mortales menores escribir código.

Raramente.

Sus métodos deben ser lo suficientemente pequeños / simples como para ser compilados y ejecutados por su mente, las pruebas unitarias deben cubrir la funcionalidad. Si encuentra un error, escriba una prueba. Ejecútalo, arréglalo.

Solo tiendo a usar el depurador cuando tengo un comportamiento inesperado de un código no comprobable, como el marco ASP.NET.

En Smalltalk, desarrollo casi por completo en el depurador:

1. Escribe una prueba que sé que fallará.
2. Ejecute la prueba Cuando falla, aparece el depurador.
3. Escriba, en el depurador, el código necesario para hacer pasar la prueba.
4. Reanudar la ejecución.
5. Si obtengo luz verde, vaya al paso 1 con una nueva prueba de falla. De lo contrario, en el depurador descubra lo que hice mal y corríjalo.

Yo uso un depurador cuando lo necesito. Eso no es diario, pero ocurre ocasionalmente. A veces es mejor recorrer el código para ver qué sucede exactamente.

Debo admitir que uso depuradores cada vez menos. He estado desarrollando en Delphi por más de 10 años. También escribo procedimientos almacenados en PL / SQL. Desde hace un par de meses, también soy desarrollador de PHP.

Utilizo principalmente el depurador en cualquiera de estos casos si encuentro un código oscuro que se escribió hace años y necesito modificarlo. A veces ayuda descubrir la forma exacta en que funciona un programa si es difícil leer el código. En PHP eso casi nunca es necesario, pero en Delphi, que se basa en eventos, a veces ayuda cuando tienes un marco complejo.

Pero como usted dice, usar el depurador es una excepción. La mayoría de los problemas se resuelven simplemente leyendo el código y arreglando cualquier error que usted (u otra persona) haya cometido.

Pero eso va para recorrer el código. A menudo uso la pila de llamadas cuando ocurre una excepción, y ocasionalmente pongo un punto de interrupción en algún lugar para inspeccionar una variable. Pero casi siempre en un código que necesita una refactorización completa de todos modos.

Ocasionalmente codifico sin depurador, pero solo cuando me obligan a punta de pistola, es decir. Gunge incrustado heredado en un 8051 o Z80.

En mi humilde opinión, necesita un depurador e iniciar sesión en cualquier trabajo complejo. Una vez no es un sustituto de la otra. Un sistema de registro no puede ayudar si la aplicación incluye un controlador, por ejemplo, donde lo único que puede hacer el código es interactuar con el hardware y establecer un semáforo.

Un depurador no puede ayudar con un error del sistema en el que las aplicaciones funcionan bien de acuerdo con la forma en que las escribió, pero el sistema aún no funciona debido a un error de protocolo de comunicaciones intermitente.

Por lo tanto, necesito el depurador para eliminar los errores estúpidos y evidentes y los errores de hardware. Necesito un buen registro para detectar errores intermitentes en la integración del sistema.

Tengo que tener ambas cosas. ¡Necesito toda la ayuda que pueda obtener!

Solo uso un depurador cuando estos pasos fallan:

1. Obtenga el error reproducible. Pensar. Esto es a menudo todo lo que se necesita.
2. Verifique cualquier rastro de pila y registros.
3. Agregue más registros alrededor del código ofensivo.

Estos pasos se encargan del 95% de todos los casos. Eso significa que rara vez uso un depurador, y cuando lo hago, tiende a darme demasiada información y me atasco en detalles no relacionados. Esto es especialmente cierto si se trabaja en un sistema de subprocesos múltiples en tiempo real.

Por lo tanto, las declaraciones de registro colocadas juiciosamente recorren un largo camino.

¿Podría ser simplemente que los programadores con mucha experiencia son los mismos que los programadores muy antiguos, y aprendieron a programar y formaron sus hábitos, cuando los depuradores no siempre estaban disponibles, y a veces no eran muy buenos?

Si se vuelve realmente bueno en la depuración de printf (y en los años ochenta, no teníamos muchas opciones, pero llegar a ser realmente bueno), tal vez un depurador no agrega tanto.

Es una cuestión de elección personal.

Honestamente, creo que los depuradores son útiles en ciertas situaciones en las que ayuda mucho saber qué hay en su ram en cualquier paso dado de la ejecución de su programa.

La utilidad principal de un depurador es detener un programa sin que el programa esté diseñado para detenerse a sí mismo: esta característica es bastante importante.

Aparte de esas 2 características, no creo que sea realmente necesario un depurador; cualquier programa complejo que realice debe tener algún tipo de modo "detallado", es decir, contar todo lo que está haciendo con printf o std :: cout, qué opciones tomó y muchos otros parámetros.

Imagínese que crea un programa y el usuario tiene problemas para usarlo: ¿cómo saber si lo está usando de la manera en que fue diseñado para usarlo, o si la cosa de la que se queja podría ser un error?

Los depuradores son como la dirección eléctrica de su automóvil: es más cómodo tener uno, pero no mejorará su manejo.

La programación es sobre diseño y lógica, la forma en que las herramientas pueden ayudarlo a rastrear cosas no lo convierte en un mejor programador.

Además, los depuradores son útiles para los lenguajes compilados, y mucho menos para los interpretados.