¿Los programadores reales usan depuradores? [cerrado]

13

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 es en qué circunstancias usted, como programador experimentado, usaría un depurador?

    
pregunta 3 revs, 3 users 67%Neil Butterworth 12.08.2012 - 17:40

15 respuestas

42

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

    
respondido por el mikerobi 21.05.2011 - 18:48
28

Utilizo el depurador a menudo, porque trabajo en un sistema grande y, por lo tanto, apesto. enlace

No importa lo breve y frecuente que lea su código, siempre existe la posibilidad de que tenga errores. enlace

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

Si el código es lo suficientemente corto, entonces las pruebas simples serán suficientes. Además, si es breve y conoce la naturaleza del error, la lectura del código puede ser suficiente. Sin embargo, una vez que el código base 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, estará perdiendo mucho tiempo.

Entonces, ¿cuándo no necesito un depurador?

No soy el codificador más inteligente, ni el más experimentado, pero aún así, a veces no necesito usar el depurador. Es entonces 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 dependo mucho de un depurador?

  • Respuesta corta: a menudo .
  • Cuando una aplicación falla. Particularmente cuando se despliega. Tener instalado VS2010 en esa computadora puede hacer una diferencia entre "Error desconocido" y FileNotFoundException .
  • Cuando una biblioteca de terceros se bloquea o se comporta mal.
  • Cuando el código está mal escrito. En particular, si el mismo archivo fue tocado por 10 personas diferentes en los últimos 10 años, 7 de las cuales ya no están en la empresa.
  • Cuando el proyecto es grande
  • Cuando el código es más bien 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 procesos almacenados) y también el generador de perfiles de SQL (para averiguar a qué SP se está llamando). ¿Necesitaría herramientas de este calibre en el que estaba escribiendo un script de Python de 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 es rápido? ¿experto? ¿Es bueno en los algoritmos? ¿Escribe buena documentación? ¿Cuándo exactamente uno se gradúa en este nuevo título? ¿Cuándo se cruza la línea mágica?

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

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

...

Ahora, en teoría, podría leer el código base durante tanto tiempo, que simplemente lo obtendría. Sin embargo, el enfoque práctico funciona mejor, y 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 el código base en el que estoy. Entonces, usar el depurador es un primer paso obvio. Solo cuando descubro cuál de los 5 millones de líneas de código está actuando, escaneo el archivo hacia arriba y hacia abajo para intentar averiguar qué está haciendo esa clase.

    
respondido por el Job 22.05.2011 - 00:52
16

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

Por otra parte, no tiene una cuenta de desbordamiento de pila, por lo que no estoy seguro de que esté interesado en su opinión :)

    
respondido por el Adam Byrtek 21.05.2011 - 19:30
11
  

Así que mi pregunta específica es respondible    en qué circunstancias lo harías,   Como un programador experimentado, use un   depurador?

  • Cuando no puedes "depurar" al leer tu código.
  • Cuando no puedes predecir qué valores ciertas variables tienen un tiempo determinado.
  • Cuando su modelo mental de su código no se ajusta a la salida dada por su código

Editar:

Tuve la fortuna / 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 100x más productivo en la búsqueda de errores.

    
respondido por el Darknight 21.05.2011 - 20:39
8

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 utilizo un depurador.

En ocasiones, un depurador puede ser una herramienta increíble y siempre que puedo compilar y ejecutar código en un escritorio, siempre uso un depurador.

En el chip, con restricciones en tiempo real, existe una gran carga asociada con el uso de un depurador. Tan pronto como se 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 e IO en código de tiempo crítico es la mejor herramienta y la más sencilla. No es tan bueno como un depurador, pero es mucho más barato trabajar con un sistema real.

    
respondido por el Luke Graham 21.05.2011 - 20:00
7

Creo que los programadores experimentados utilizan casi exclusivamente los depuradores cuando son necesarios. ¿Qué mejor manera de rastrear un error que seguir realmente la ejecución del código ...

¿Supones 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 van a ser investigados. Por lo tanto, las opciones son utilizar declaraciones de impresión, en un extremo del espectro, o examinar examinar lo que sucedió, post mortem, en el otro, o mirar directamente en el medio a medida que se ejecuta el código y descubrir qué está pasando.

Tal vez una mejor manera de pensarlo es que los programadores experimentados saben cuándo usar un depurador. En el código con pocas dependencias, mirar un seguimiento de pila es probablemente suficiente para descubrir qué es lo que está mal. Pero hay escenarios complicados en los que tu código funciona con otro código, y necesitas un depurador para ver las cosas que no escribiste.

    
respondido por el hvgotcodes 21.05.2011 - 18:47
4

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

    
respondido por el Kevin 21.05.2011 - 18:49
4

¿A quién 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?

Algunos programadores, probablemente mejores que el resto de nosotros, encontraron la necesidad de un depurador y crearon 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 para permitir que los mortales menores escriban código.

    
respondido por el JeffO 21.05.2011 - 20:45
3

Rara vez.

Sus métodos deben ser lo suficientemente pequeños / simples para ser compilados y ejecutados por su mente, las pruebas unitarias deben cubrir la funcionalidad. Si encuentras un error, escribe una prueba. Ejecutarlo, arreglarlo.

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

    
respondido por el Andrew Bullock 21.05.2011 - 18:51
3

En Smalltalk, desarrollo casi por completo en el depurador:

  1. Escriba una prueba que sé que fallará.
  2. Ejecutar la prueba. Cuando falla, el depurador aparece.
  3. Escriba, en el depurador, el código necesario para realizar la prueba.
  4. Reanudar ejecución.
  5. Si obtengo una luz verde, vaya al paso 1 con una nueva prueba que falla. De lo contrario, en el depurador, averigüe qué hice mal y corríjalo.
respondido por el Frank Shearar 21.05.2011 - 19:49
2

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

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

Utilizo principalmente el depurador en cualquiera de estos casos si encuentro un fragmento de código oscuro que fue escrito hace años y necesito modificarlo. A veces es útil 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 dices, usar el depurador es una excepción. La mayoría de los problemas se resuelven simplemente leyendo el código y corrigiendo cualquier error que usted (o alguien más) haya cometido.

Pero eso va para pasar a través del código. Con bastante frecuencia uso la pila de llamadas cuando ocurre una excepción, y ocasionalmente coloco un punto de interrupción en algún lugar para inspeccionar una variable. Pero casi siempre en un trozo de código que necesita una refactorización completa de todos modos.

    
respondido por el GolezTrol 21.05.2011 - 19:01
2

De vez en cuando codifico sin depurador, pero solo cuando me veo forzado a apuntar con la pistola, es decir. legado gunge incrustado 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 para el otro. Un sistema de registro no puede ayudar si la aplicación se mete en 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 donde las aplicaciones funcionan bien de acuerdo con la forma en que las escribiste, pero el sistema todavía no funciona debido a algún error de protocolo de comunicaciones intermitentes.

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

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

    
respondido por el Martin james 10.04.2012 - 22:29
1

Solo uso un depurador cuando estos pasos fallan:

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

Estos pasos se encargan del 95% de todos los casos. Eso significa que rara vez utilizo 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 multiproceso en tiempo real.

Las declaraciones de registro colocadas de manera tan juiciosa ayudan mucho.

    
respondido por el Martin Wickman 21.05.2011 - 19:38
1

¿Podría ser simplemente que los programadores muy experimentados son lo mismo que los programadores muy viejos, y aprendieron a programar y formaron sus hábitos cuando los depuradores no siempre estaban disponibles y, a veces, no eran muy buenos?

Si te vuelves realmente bueno en la depuración de printf (y en los años ochenta, no tuvimos muchas opciones más que ser realmente buenos), tal vez un depurador no agregue tanto.

    
respondido por el Thomas Padron-McCarthy 21.05.2011 - 20:59
0

Es una cuestión de elección personal.

Honestamente, creo que los depuradores son útiles en ciertas situaciones en las que ayuda mucho saber lo que pasa en tu memoria RAM en cualquier paso dado de la ejecución de tu 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 muy importante.

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

Imagínate que creas un programa, y el usuario tiene un problema al usarlo: ¿cómo saber si lo está utilizando de la forma en que fue diseñado para ser utilizado, o si lo que él reclama podría ser un error? / p>

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.

Progamming es sobre diseño y lógica, la forma en que las herramientas pueden ayudarlo a realizar el seguimiento de las cosas no lo convierte en un mejor programador.

Los depuradores

Plus son útiles para los lenguajes compilados, y mucho menos para los interpretados.

    
respondido por el jokoon 22.05.2011 - 06:50

Lea otras preguntas en las etiquetas