No lo hagas
La depuración debería ser un acto de último recurso. Debe tener una metodología de desarrollo de programas que reduzca la necesidad de depurar en primer lugar.
En particular, debe escribir ejemplos de su código antes de escribir su código. Luego escribe más ejemplos, también conocidos como pruebas. (Consulte Cómo diseñar programas, y en particular la respuesta de Shriram Krishnamurthi a ¿Cómo enseña el profesor Shriram Krishnamurthi el concepto de recursión?). Si su programa no funciona correctamente y todas sus pruebas pasan, significa que no ha realizado la prueba lo suficientemente bien.
- ¿Algún consejo para estudiar la complejidad del espacio para programar entrevistas? ¿Cuáles son algunos buenos recursos para aprender sobre la complejidad del espacio?
- ¿En qué se diferencia la programación dinámica del seguimiento hacia atrás?
- Juez en línea de Esfera (SPOJ): ¿Por qué el siguiente código da como resultado TLE? Quiero saber cómo se puede optimizar mi código para evitarlo.
- ¿Puedo colaborar con R y Python en la misma página web?
- ¿Cómo 'entiende' el hardware de la computadora los dígitos binarios?
Entonces, el siguiente paso es sondear el espacio de las entradas para encontrar una falla. Tenga en cuenta que para saber si algo falla, debe saber cuál es la salida esperada (porque una prueba relaciona entradas y salidas). Si no puede averiguar qué debe producir una entrada, tiene un problema mucho más fundamental: no sabe qué programa está tratando de escribir. Aléjese de la computadora y descubra eso primero.
Ahora, supongamos que ha llegado a este punto: tiene entradas con salidas esperadas de que el programa está fallando. Aquí hay algo realmente bueno: ¡La recursión funciona muy bien con las pruebas! Si tiene una función no recursiva, podría haber varias razones por las cuales la salida de la entrada dada no es correcta. Pero si es recursivo, (casi siempre) está creando un subproblema de la entrada errónea dada. Por lo tanto, no tiene que buscar helter-skelter para obtener una explicación del error. Descubre los subproblemas que está generando y cuáles son sus resultados esperados. Comprueba si están produciendo eso.
- Si no, estás lidiando con un caso de falla demasiado grande cuando tienes uno más pequeño a mano, así que desciende recursivamente.
- Si lo son, entonces ha aislado su problema. Tiene subproblemas que producen resultados correctos, pero la composición de las soluciones está fallando. Ahora deberías poder recorrer su composición para descubrir la falla.
Como beneficio adicional de seguir este protocolo de “depuración”, ahora ha agregado más pruebas a su código, y en particular ha agregado pruebas de regresión. Debido a que se sabe que los errores reaparecen (es decir, se sabe que el código regresa), detectará este o un error estrechamente relacionado temprano si ocurre nuevamente en el futuro.
NB: Supongo que estás programando de una manera principalmente funcional, porque eso es lo que todos deberían hacer de todos modos. (-: