Al depurar, a veces encuentro que hago algunos cambios y no estoy 100% seguro de por qué esos cambios corrigen algún error en el programa. ¿Es esencial comprender cada detalle sobre por qué ocurrieron algunos errores y por qué ciertos cambios eliminaron esos errores? ¿O es común entre los desarrolladores hacer que el programa funcione a veces sin conocer realmente los detalles sobre por qué funcionó la solución?
Diría que es esencial comprender cada detalle sobre por qué ocurrieron algunos errores y por qué ciertos cambios eliminaron esos errores, y también es común entre los desarrolladores hacer que el programa funcione a veces sin ¡realmente conociendo los detalles sobre por qué funcionó la solución!
El arte de cambiar las cosas hasta que desaparece un error, sin entender qué lo causó o por qué el cambio lo solucionó, a menudo se llama "programación de vudú" y no es un cumplido. Realmente no hay forma de que puedas estar seguro de que realmente hayas arreglado un error, en lugar de corregirlo parcialmente para el caso particular que estabas investigando, si no entiendes la causa.
En el peor de los casos, no has hecho nada, excepto mover el error: recuerdo desde el primer año de cómputo en la universidad, cuando muchos estudiantes estaban aprendiendo C e indicadores por primera vez, los errores de puntero a menudo dejaban de manifestarse cuando cambiaron las cosas al azar, porque los cambios reorganizarían las estructuras de datos en la memoria lo suficiente como para que el error del puntero se detuviera en un bit de memoria diferente. Obviamente eso no ha ayudado a en absoluto .
Pero habiendo dicho eso, las realidades comerciales de la programación son a menudo tales que satisfacer al cliente de que se solucione un error es más importante que satisfacerse a usted mismo. Nunca recomendaría que declararas algo fijo si no tenías ni idea lo que lo causó, pero si puedes ver que algún código fue problemático y lo reelaboró, incluso si "no estás al 100% seguro "cómo eso hizo que el error específico se manifestara, a veces solo tienes que pasar al siguiente error antes de que el cliente grite demasiado fuerte sobre tu lento progreso.
Si piensa que un cliente está enojado porque se demora demasiado en solucionar un error, imagine cuán enojado estará por el hecho de que un error recurrente que usted reclamó fue arreglado, o una solución para una cosa que empeora algo más. Si su solución es solo una solución o mitigación, los clientes generalmente lo agradecerán, pero debe ser sincero acerca de lo que es, y debe poner todo el registro necesario para corregirlo de verdad.
Si estás bastante seguro de que lo arreglaste, pero no sabes por qué funciona la solución, pregúntale a alguien. La mayoría de los ingenieros que conozco a amor para obtener preguntas de este tipo debido al misterio que hay detrás.
Cambiar cosas hasta que el error ya no existe, 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 qué hace o por qué lo hace. ¿Cómo puedes estar seguro de que aunque hayas solucionado el error que te propusiste solucionar, no has 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 debes leer el código y entender por qué el código está causando que ocurra el error. Una vez que tenga esa comprensión: entonces puede comenzar a ver cómo resolver el problema y determinar otras áreas que afectarán sus cambios. ¡Las pruebas unitarias realmente pueden ayudar aquí!
He visto una serie de cambios de 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 "correcciones" simplemente ocultan la causa subyacente del problema original, así como la introducción de complejidad y más errores.
Habiendo dicho eso, he solucionado una serie de problemas en el código exclusivamente por asociación. Donde he cambiado / reelaborado / refactorizado algo y se han solucionado otros errores pendientes. Así que, aunque no sé qué los causó originalmente, encontré un código poco fiable y lo "reparé", lo que también solucionó esos errores. Cubro cambios como este con pruebas de unidad e integración para garantizar la integridad del negocio y los requisitos técnicos de la función.
O es común entre los desarrolladores hacer que el programa funcione a veces sin realmente saber los detalles de por qué funcionó la solución?
Hay al menos tres grandes problemas con eso:
Conduce a una mentalidad de magia negra en la que renuncias a la idea de que puedes entender el código y, en lugar de eso, simplemente comienzas a mover las partes con la esperanza de que los problemas desaparezcan. Esta es la programación equivalente a empujar la comida alrededor de su plato, con la esperanza de que su cena se vea lo suficientemente consumida para que sus padres no le hagan comer más de sus vegetales.
No puede saber si el error está realmente arreglado o simplemente está enmascarado por su cambio a menos que entienda a) cuál fue el problema, yb) cómo su cambio resuelve el problema.
Probablemente el error no se haya solucionado y te volverá a atacar en un futuro próximo.
Veo dos escenarios: trabajaste en otra cosa y el error dejó de suceder, siempre que la otra cosa no haya roto ninguna otra cosa, tienes que dejar que eso entre, hiciste lo que se necesitaba / quería. y tuvo un efecto secundario positivo imprevisto e inexplicable.
La otra es que estás trabajando en este error y un cambio aleatorio hizo que las cosas funcionen, eso es inaceptable. Si no tiene idea de lo que el código anterior estaba haciendo mal, probablemente no tenga idea de lo que el código nuevo está haciendo mal.
Realmente no puedo pensar en una buena razón para verificar el segundo caso: si se trata de un error crítico, entonces es fundamental hacerlo bien. Si es 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 hacer que el programa funcione a veces sin realmente saber los detalles de por qué funcionó la solución?
Por mi parte, creo que es muy muy común en estos días. Eso es debido a Google y Stackoverflow. Tiene un problema con su código, solo busque en Google, encuentre una solución, solucione, pase al siguiente problema.