Cerrado . Esta pregunta debe estar más
centrada . Actualmente no acepta respuestas.
Comentarios
Respuesta
La mentalidad y la actitud hacia la depuración es quizás la la parte más importante, porque determina la eficacia con la que solucionará el error y lo que aprenderá de él, si es que algo.
Los clásicos del desarrollo de software como The Pragmatic Programmer y Code Complete básicamente defienden el mismo enfoque: cada error es una oportunidad para aprender, casi siempre sobre ti mismo (porque solo los principiantes culpan primero al compilador / computadora).
Así que trátelo como un misterio que será interesante de descifrar. Y descifrar ese misterio debe hacerse de forma sistemática, expresando nuestras suposiciones (a nosotros mismos oa otros) y luego probando nuestras suposiciones, una por una si es necesario, utilizando todas las herramientas a nuestra disposición, especialmente depuradores y marcos de prueba automatizados. Luego, una vez resuelto el misterio, puede hacerlo aún mejor examinando todo el código en busca de errores similares que haya cometido; y escribir una prueba automatizada para garantizar que el error no vuelva a ocurrir sin saberlo.
Una última nota: prefiero llamar a los errores «errores» y no «errores». Dijkstra reprendió a sus colegas por usar este último término porque es deshonesto, apoyar la idea de que las hadas de insectos perniciosas y volubles plantaron errores en nuestros programas mientras no estábamos mirando, en lugar de estar allí debido a nuestro propio (descuidado) pensamiento: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html
Podríamos, por ejemplo, comenzar a limpiar nuestro idioma ya no llamando error a un error, sino llamándolo error. Es mucho más honesto porque echa directamente la culpa a donde pertenece, a saber. con el programador que cometió el error. La metáfora animista del error que se coló maliciosamente mientras el programador no estaba mirando es intelectualmente deshonesta, ya que disfraza que el error es creación del programador. Lo bueno de este simple cambio de vocabulario es que tiene un efecto tan profundo : mientras que antes un programa con un solo error solía ser «casi correcto», después un programa con un error es simplemente «incorrecto» (porque es un error).
Comentarios
Responder
-
Escribe pruebas. Las pruebas no solo son excelentes para prevenir errores (en mi experiencia, TDD bien hecho elimina casi todos los errores triviales y estúpidos), sino que también ayuda mucho en la depuración. Las pruebas obligan a su diseño a ser bastante modular, lo que facilita mucho el aislamiento y la reproducción del problema. Además, controlas el entorno, por lo que habrá muchas menos sorpresas. Además, una vez que obtenga un caso de prueba fallido, puede estar razonablemente seguro de que «ha descubierto la razón real del comportamiento que le molesta.
-
Aprenda a usar un depurador. Las declaraciones print pueden funcionar razonablemente bien en algún nivel, pero un depurador la mayor parte del tiempo es muy útil (y una vez sabe cómo usarlo, es mucho más cómodo que las print declaraciones).
-
Hable de alguien sobre su problema, incluso si es solo un patito de goma . Obligarse a expresar el problema en el que está trabajando en palabras realmente hace milagros.
-
Establezca un límite de tiempo. Si, por ejemplo, después de 45 minutos siente que no va a ninguna parte, simplemente cambie a otras tareas durante algún tiempo. Cuando vuelva a su error, con suerte podrá ver otras posibles soluciones que no habría considerado antes.
Comentarios
Respuesta
Me gustan la mayoría de las otras respuestas, pero aquí hay algunos consejos sobre qué hacer ANTES de hacer nada de eso. Le ahorrará mucho tiempo.
-
Determine si realmente hay un error. Un error es SIEMPRE una diferencia entre el comportamiento y los requisitos del sistema; el evaluador debe poder articular el comportamiento esperado y real. Si no puede brindar soporte para el comportamiento esperado, no hay ningún requisito y no hay ningún error, solo la opinión de alguien. Envíela de regreso.
-
Considere la posibilidad que el comportamiento esperado es incorrecto. Esto podría deberse a una mala interpretación del requisito. También podría deberse a un defecto en el propio requisito (un delta entre un requisito detallado y un requisito comercial). También puede devolverlos.
-
Aislar el problema. Solo la experiencia le enseñará la forma más rápida de hacerlo; algunas personas casi pueden hacerlo con su instinto. Un enfoque básico es variar una cosa mientras manteniendo todas las demás cosas constantes (¿el problema ocurre en otros entornos? ¿Con otros navegadores? ¿En una región de prueba diferente? ¿En diferentes momentos del día?) Otro enfoque es mirar los volcados de pila o los mensajes de error; a veces se puede por cierto, está formateado qué componente del sistema arrojó el error original (por ejemplo, si está en alemán, puede bla yo ese tercero con el que trabaja en Berlín).
-
Si lo ha reducido a dos sistemas que colaboran, inspeccione los mensajes entre los dos sistemas a través del monitor de tráfico o archivos de registro y determinar qué sistema se está comportando según las especificaciones y cuál no. Si hay más de dos sistemas en el escenario, puede realizar comprobaciones por pares y avanzar en la pila de aplicaciones.
-
La razón por la que aislar el problema es tan crítico es que el problema puede no deberse a un defecto en el código sobre el que usted tiene control (por ejemplo, sistemas de terceros o el entorno) y desea que esa parte se haga cargo lo más rápido posible. Esto es tanto para ahorrarle trabajo como para ponerlos a punto de inmediato para que la resolución se pueda lograr en el menor tiempo posible. No desea trabajar en un problema durante diez días solo para descubrir que realmente es un problema con el servicio web de otra persona.
-
Si ha determinado que realmente hay un defecto y realmente está en el código que controla, puede aislar aún más el problema buscando la última compilación «buena conocida» e inspeccionar los registros de control de fuente en busca de cambios que puedan haber causado el problema. Esto puede ahorrar mucho tiempo.
-
Si no puede averiguarlo desde el control de código fuente, ahora es el momento de adjuntar su depurador y recorrer el código para averiguarlo Lo más probable es que ya tenga una idea bastante clara del problema.
Una vez que sepa dónde está el error y pueda pensar en una solución, aquí encontrará una buena procedimiento para solucionarlo:
-
Escriba una prueba unitaria que reproduzca el problema y falle.
-
Sin modificar la prueba unitaria, haga pasa (modificando el código de la aplicación).
-
Mantenga la prueba unitaria en su suite de pruebas para prevenir / detectar regresiones.
Respuesta
Creo que la reproducción de un error también es importante. Todos los casos que reproducen el error se pueden enumerar y luego puede asegurarse de que su corrección de error cubra todos esos casos.
Respuesta
Hay un libro excelente que leí sobre este tema llamado Por qué fallan los programas , que describe varias estrategias para encontrar errores que van desde la aplicación del método científico hasta aislar y resolver un error, a la depuración delta. La otra parte interesante de este libro es que elimina el término «error». El enfoque de Zeller es:
(1) Un programador crea un defecto en el código. (2) El defecto provoca una infección (3) La infección se propaga (4) La infección provoca un fallo.
Si desea mejorar sus habilidades de depuración, le recomiendo este libro.
En mi propia experiencia personal, he encontrado muchos errores en nuestra aplicación, pero la administración simplemente nos presiona. para sacar nuevas funciones. «He escuchado con frecuencia» Nosotros mismos encontramos este error y el cliente aún no lo ha notado, así que déjelo hasta que lo haga «. Creo que ser reactivo en lugar de proactivo en la corrección de errores es una muy mala idea, ya que cuando llega el momento de solucionarlo, tienes otros problemas que deben resolverse y la administración de más funciones quiere salir por la puerta lo antes posible, para que te atrapen. en un círculo vicioso que puede generar una gran cantidad de estrés y agotamiento y, en última instancia, un sistema lleno de defectos.
La comunicación también es otro factor cuando se encuentran errores. Enviar un correo electrónico o documentarlo en el El rastreador de errores está muy bien, pero en mi propia experiencia, otros desarrolladores encuentran un error similar y en lugar de reutilizar la solución que pusiste para arreglar el código (ya que se han olvidado por completo), agregan sus propias versiones, por lo que tienes 5 soluciones diferentes en tu código y, como resultado, se ve más hinchado y confuso. Así que, cuando arregles un error, asegúrate de que algunas personas revisen la corrección y te den su opinión en caso de que hayan solucionado algo similar y encontró una buena estrategia para lidiar con eso.
Limist mencionó el libro,
El programador pragmático que tiene material interesante sobre la corrección de errores. Usando el ejemplo que di en el párrafo anterior, vería esto: Software Entrophy , donde se usa la analogía de una viuda rota. Si dos muchas rotas Si aparecen ventanas, su equipo puede volverse apático para solucionarlo a menos que adopte una postura proactiva.
Comentarios
Error, error, problema, defecto – como quieras llamarlo, no hace mucha diferencia. Me limitaré al problema ya que «es a lo que estoy acostumbrado».
- Averigüe cuál es la percepción del problema: traduzca de la «s» de un cliente, Bob todavía no está en el sistema «a» Cuando intento crear un registro de usuario para Bob, falla con una excepción de clave duplicada, aunque Bob «no está ya ahí»
- Averigüe si «realmente es un problema o simplemente un malentendido (de hecho, Bob no lo está» t allí, no hay nadie llamado bob, y la inserción debería funcionar).
- Intente obtener pasos mínimos confiables que pueda seguir para reproducir el problema – algo como «Dado un sistema con un registro de usuario» Bruce «, cuando se inserta un registro de usuario» Bob «, se produce una excepción»
- Esta es su prueba; si es posible, colóquela en un Pruebe el arnés que puede ejecutar una y otra vez, esto será invaluable al depurar. También puede convertirlo en parte de su conjunto de pruebas para asegurarse de que ese problema en particular no vuelva a aparecer más adelante.
- Saque el depurador y comience a poner puntos de interrupción: descubra la ruta del código cuando ejecute la prueba, e identificar lo que está mal. Mientras lo hace, también puede refinar su prueba haciéndola lo más estrecha posible, idealmente una prueba unitaria.
- Solucionarla: verifique que la prueba pase.
- Verifique el problema original como lo describe el cliente también es fijo (muy importante, es posible que haya solucionado un subconjunto del problema). Verifique que no introdujo regresiones en otros aspectos del programa.
Si está muy familiarizado con el código, o si el problema o la solución es obvio, puede omitir algunos de esos
¿Cómo deberíamos abordarlo para hacer un uso más eficaz de nuestro valioso tiempo y permitirnos dedicar menos tiempo a buscarlo y más a codificar ?
No estoy de acuerdo con eso, ya que implica que escribir código nuevo es más valioso que tener un programa de trabajo de alta calidad. No hay nada de malo en ser lo más eficaz posible para solucionar problemas, pero un programa no necesariamente mejora con solo agregarle más código.
Comentarios
Cuando detectamos un error en nuestro código, ¿qué podemos hacer para eliminarlo? ¿Cómo deberíamos abordarlo para hacer un uso más eficaz de nuestro valioso tiempo y permitirnos dedicar menos tiempo a buscarlo y más a codificar? Además, ¿qué debemos evitar al depurar?
Suponiendo que se encuentra en un entorno de producción, esto es lo que debe hacer:
-
Describa el «error» correctamente e identifique los eventos que lo causaron.
-
Determine si el «error» es un error de código o error de especificación. Por ejemplo, ingresar un nombre de 1 letra puede considerarse un error para algunos sistemas, pero un comportamiento aceptable para otros sistemas. A veces, un usuario informa de un error que cree que es un problema, pero las expectativas del usuario sobre el comportamiento del sistema no formaban parte de los requisitos.
-
Si han demostrado que existe un error y el error se debe al código, entonces puede determinar qué partes del código deben corregirse para evitar el error. También examine el efecto del comportamiento en los datos actuales y las operaciones futuras del sistema (análisis de impacto en código y datos).
-
En este punto probablemente tendrá una estimación de la cantidad de recursos que se van a consumir para corregir el error. Puede corregirlo de inmediato o programar una solución dentro de una próxima versión del software.Esto depende también de si el usuario final está dispuesto a pagar por la solución. También debe evaluar las diferentes opciones disponibles para corregir el error. Puede haber más de una forma. Debe seleccionar el enfoque que mejor se adapte a la situación.
-
Analice las razones que causaron la aparición de este error (requisitos, codificación, pruebas, etc.). Haga cumplir los procesos que evitarían que la condición vuelva a ocurrir.
-
Documente el episodio de manera adecuada.
-
Libere la solución (o la nueva versión)