Depuración: ¿comprende detalles sobre por qué funcionaron ciertas correcciones? [cerrado]

Al depurar, a veces encuentro que hago algunos cambios y no estoy 100% seguro de por qué esos cambios corrigen algunos errores en el programa. ¿Es esencial comprender cada detalle sobre por qué se produjeron algunos errores y por qué ciertos cambios eliminaron esos errores? ¿O es común entre los desarrolladores a veces hacer que el programa funcione sin saber realmente los detalles sobre por qué funcionó la solución?

Diría que es esencial comprender cada detalle sobre por qué se produjeron algunos errores y por qué ciertos cambios eliminaron esos errores, y también es común entre los desarrolladores a veces hacer que el programa funcione sin saber realmente los detalles sobre por qué funcionó la solución.

El arte de cambiar las cosas hasta que un error desaparece, sin entender qué lo causó o por qué el cambio lo solucionó, a menudo se llama "programación vudú", y no es un cumplido. Realmente no hay forma de que pueda estar seguro de que ha solucionado genuinamente un error, en lugar de corregirlo parcialmente para el caso particular que estaba investigando, si no comprende qué lo causó.

En el peor de los casos, no ha hecho nada más que mover el error: recuerdo de la computación del primer año en la universidad, cuando muchos estudiantes estaban aprendiendo C y punteros por primera vez, los errores de puntero a menudo dejaban de manifestarse cuando cambiaban las cosas. aleatoriamente, porque los cambios reorganizarían las estructuras de datos en la memoria lo suficiente como para hacer que el error del puntero pisotee un bit de memoria diferente. Obviamente eso no ha ayudado en absoluto .

Pero dicho esto, las realidades comerciales de la programación son a menudo tales que satisfacer al cliente de que se solucionó un error es más importante que satisfacerse a sí mismo. Nunca recomendaría que declarara algo arreglado si no tenía idea de qué lo causó, pero si puede ver que algún código fue problemático y lo modificó, incluso si no está "100% seguro" de cómo eso causó el problema específico error para manifestarse, a veces solo tiene que pasar al siguiente error antes de que el cliente grite demasiado fuerte sobre su lento progreso.

Si cree que un cliente está enojado porque le tomó demasiado tiempo reparar un error, imagine lo enojado que estará con un error recurrente que, según usted, se solucionó, o una solución para una cosa que empeora otra cosa. Si su solución es solo una solución o mitigación, los clientes generalmente la recibirán con agrado, pero debe ser honesto acerca de lo que es, y colocar todo el registro que necesite para arreglarlo de verdad.

Si está seguro de haberlo solucionado, pero no sabe por qué funciona, pregúntele a alguien. La mayoría de los ingenieros que conozco adoran recibir preguntas como esa debido al misterio detrás de esto.

Cambiar cosas hasta que el error ya no exista generalmente es una mala práctica, pero desafortunadamente es una realidad para algunas personas.

Soy de la firme opinión de que nunca debes escribir código que no entiendas lo que hace o por qué lo hace. ¿Cómo puede estar seguro de que, aunque haya solucionado el error que se propuso solucionar, no haya roto nada más?

En general, antes de solucionar un problema / error, debe realizar una evaluación / análisis de la causa subyacente para determinar por qué ocurre el problema y si se puede replicar. Entonces debería leer el código y comprender por qué el código está causando el error. Una vez que tenga esa comprensión: entonces puede comenzar a ver cómo resuelve el problema y determinar otras áreas que afectarán sus cambios. ¡Las pruebas unitarias realmente pueden ayudar aquí!

He visto una serie de cambios en el código que la gente ha hecho para solucionar un problema (lo cual es genial), pero desafortunadamente introdujo otros problemas porque el desarrollador no estaba al tanto del impacto total de lo que cambiaron. Muchas de estas "soluciones" simplemente ocultan la causa subyacente del problema original, además de introducir complejidad y más errores.

Dicho esto, he solucionado una serie de problemas en el código simplemente por asociación. Donde he cambiado / reelaborado / refactorizado algo y solucionó otros errores pendientes. Entonces, aunque no sé qué los causó originalmente, encontré un código dudoso y lo "solucioné", lo que también solucionó esos errores. Cubro cambios como este con pruebas de unidad e integración para garantizar la integridad de los requisitos comerciales y técnicos de la función.

¿O es común entre los desarrolladores a veces hacer que el programa funcione sin saber realmente los detalles sobre por qué funcionó la solución?

Hay al menos tres grandes problemas con eso:

1. Conduce a una mentalidad de magia negra en la que renuncias a la idea de que puedes entender el código y, en cambio, simplemente comienzas a mover partes esperando que los problemas desaparezcan. Este es el equivalente de programación de empujar la comida en su plato, con la esperanza de que su cena se vea lo suficientemente comida como para que sus padres no lo obliguen a comer más verduras.

2. No puede saber que el error está realmente solucionado o simplemente enmascarado por su cambio a menos que comprenda a) cuál era el problema yb) cómo su cambio resuelve el problema.

3. El error probablemente no esté solucionado , y lo morderá nuevamente en un futuro cercano.

Veo dos escenarios: trabajaste en otra cosa y el error dejó de suceder, siempre y cuando la otra cosa no haya roto nada más, tienes que dejar que eso suceda: hiciste lo que era necesario / quería y tuvo Un efecto secundario positivo imprevisto e inexplicable.

El otro es que está trabajando en este error y un cambio aleatorio hizo que las cosas funcionen, eso es inaceptable. Si no tiene idea de qué estaba haciendo mal el antiguo código, probablemente no tenga idea de qué está haciendo mal el nuevo código.

Realmente no puedo pensar en una buena razón para registrar el segundo caso: si es un error crítico, entonces es crítico hacerlo bien. Si se trata de un error no crítico, al menos puede estar seguro de que no está introduciendo un error crítico con su "corrección".

¿O es común entre los desarrolladores a veces hacer que el programa funcione sin saber realmente los detalles sobre por qué funcionó la solución?

Por mi parte, creo que es muy muy común en estos días. Eso se debe a Google y Stackoverflow. Tienes un problema con tu código, solo búscalo en Google, encuentra la solución, solucionado, pasa al siguiente problema.